| Message ID | 20240104080631.3666413-1-illia.bobyr@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | rebase: clarify --reschedule-failed-exec default | expand |
On Thu, Jan 04, 2024 at 12:06:31AM -0800, Illia Bobyr wrote: > Documentation should mention the default behavior. > > It is better to explain the persistent nature of the > --reschedule-failed-exec flag from the user standpoint, rather than from > the implementation standpoint. The first paragraph looks good, and I think your wording is an improvement over what's already there (though of course this is subjective, and YMMV). > +Recording this option for the whole rebase is a convenience feature. Otherwise > +an explicit `--no-reschedule-failed-exec` at the start would be overridden by > +the presence of a `rebase.rescheduleFailedExec=true` configuration when `git > +rebase --continue` is invoked. Currently, you can not, pass > +`--[no-]reschedule-failed-exec` to `git rebase --continue`. The last sentence was a bit confusing to me. I assume you meant Currently, you cannot pass `--[no-]reschedule-failed-exec` [...] without the comma between "pass" and "`--[no]reschedule-failed-exect`", and replacing "can not" with "cannot". Thanks, Taylor
Applied. Thank you for reviewing!
Sorry, I did not actually include the change in v2. Still learning how to use git send-email. On Thu, Jan 04, 2024 at 11:20:28AM -0800, Taylor Blau wrote: > [...] > > > +Recording this option for the whole rebase is a convenience feature. Otherwise > > +an explicit `--no-reschedule-failed-exec` at the start would be overridden by > > +the presence of a `rebase.rescheduleFailedExec=true` configuration when `git > > +rebase --continue` is invoked. Currently, you can not, pass > > +`--[no-]reschedule-failed-exec` to `git rebase --continue`. > > The last sentence was a bit confusing to me. I assume you meant > > Currently, you cannot pass `--[no-]reschedule-failed-exec` [...] > > without the comma between "pass" and "`--[no]reschedule-failed-exect`", > and replacing "can not" with "cannot". Applied. Thank you for reviewing!
diff --git Documentation/git-rebase.txt Documentation/git-rebase.txt index 1dd65..45d3c 100644 --- Documentation/git-rebase.txt +++ Documentation/git-rebase.txt @@ -626,13 +626,16 @@ See also INCOMPATIBLE OPTIONS below. Automatically reschedule `exec` commands that failed. This only makes sense in interactive mode (or when an `--exec` option was provided). + -Even though this option applies once a rebase is started, it's set for -the whole rebase at the start based on either the -`rebase.rescheduleFailedExec` configuration (see linkgit:git-config[1] -or "CONFIGURATION" below) or whether this option is -provided. Otherwise an explicit `--no-reschedule-failed-exec` at the -start would be overridden by the presence of -`rebase.rescheduleFailedExec=true` configuration. +This option applies once a rebase is started. It is preserved for the whole +rebase based on, in order, the command line option provided to the initial `git +rebase`, the `rebase.rescheduleFailedExec` configuration (see +linkgit:git-config[1] or "CONFIGURATION" below), or it defaults to false. ++ +Recording this option for the whole rebase is a convenience feature. Otherwise +an explicit `--no-reschedule-failed-exec` at the start would be overridden by +the presence of a `rebase.rescheduleFailedExec=true` configuration when `git +rebase --continue` is invoked. Currently, you can not, pass +`--[no-]reschedule-failed-exec` to `git rebase --continue`. --update-refs:: --no-update-refs::
Documentation should mention the default behavior. It is better to explain the persistent nature of the --reschedule-failed-exec flag from the user standpoint, rather than from the implementation standpoint. Signed-off-by: Illia Bobyr <illia.bobyr@gmail.com> --- Documentation/git-rebase.txt | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-)