The former wording implied that --no-commit would always cause the merge operation to "pause" and allow the user to make further changes and/or provide a special commit message for the merge commit. This is not the case for fast-forward merges, as there is no merge commit to create. Without a merge commit, there is no place where it makes sense to "stop the merge and allow the user to tweak changes"; doing that would require a full rebase of some sort. Since users may be unaware of whether their branches have diverged or not, modify the wording to correctly address fast-forward cases as well and suggest using --no-ff with --no-commit if the point is to ensure that the merge stops before completing. Reported-by: Ulrich Windl <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx> Signed-off-by: Elijah Newren <newren@xxxxxxxxx> --- Changes since v1: - Tweaked commit message Documentation/merge-options.txt | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt index c2a263ba74..d1061b8cf7 100644 --- a/Documentation/merge-options.txt +++ b/Documentation/merge-options.txt @@ -3,9 +3,15 @@ Perform the merge and commit the result. This option can be used to override --no-commit. + -With --no-commit perform the merge but pretend the merge -failed and do not autocommit, to give the user a chance to -inspect and further tweak the merge result before committing. +With --no-commit perform the merge and stop just before creating +a merge commit, to give the user a chance to inspect and further +tweak the merge result before committing. ++ +Note that fast-forward updates do not need to create a merge +commit and therefore there is no way to stop those merges with +--no-commit. Thus, if you want to ensure your branch is not +changed or updated by the merge command, use --no-ff with +--no-commit. --edit:: -e:: -- 2.21.0.rc1.264.g6c9e06a32d
