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@xxxxxxxxx> --- Documentation/git-rebase.txt | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) 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:: -- 2.40.1
