On 18 April 2016 at 17:23, Christoph Paulik <cpaulik@xxxxxxxxx> wrote: > My expectations from what should happen came mainly from the description of > the --no-commit flag in the help: > > 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. > So in the case of a fast-forward the flag does not pretend that the merge > failed. Yes, I think the mis-alignment in expectations comes from a technicality in the description you quote. The fast forward is in some ways not really counted as a true merge, and no new commits are created. Thus, the merge progresses up to the point where a merge resolution would have to take place, realises that there is no merge resolution to do (it's just a fast forward!) and so exits out. Unfortunately, a side effect of this is that the fast-forward has already happened and so you are left with something different from what was expected. I do think that the --no-commit option should imply --no-ff (as this would make the behaviour consistent for end-users). I don't know if this is something that would break scripts etc, but if so you could make it implied only if we detect a terminal or something like is done in other places. Regards, Andrew Ardill -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html