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 v2: - Small wording change suggested by Junio (s/do not need to/do not/) Documentation/merge-options.txt | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt index c2a263ba74..5be89168c6 100644 --- a/Documentation/merge-options.txt +++ b/Documentation/merge-options.txt @@ -3,9 +3,14 @@ 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 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.rc2.262.g736ce73923
