BongHo Lee <techcap@xxxxxxxx> writes: > If I add --no-ff option, it works properly. > I think --no-commit option should be worked without --no-ff. It is understandable that this is confusing, but --no-commit is an instruction not to create a new commit object. As fast-forwarding to the commit that is a strict descendant of your old tip does not involve creation of any new commit, the command is working exactly as instructed. If you say "--no-ff", you are explicitly forbidding the command to fast-forward, so the command attempts to create a (needless) new commit that is a merge, and then --no-commit stops the command after it prepared the tree state ready to be committed. So with or without --no-ff, the option and the command are working correctly. Having said all that, my gut feeling is that a backward incompatible change to make --no-commit "imply" --no-ff may not hurt too many existing users, but I am saying this without thinking things through. I may very well be missing a valid use case where --no-commit that does not fail but does fast-forward when the user does not give --no-ff is useful, so if that is the case, such a change will be breaking those users.