Re: git merge branch --no-commit does commit fast forward merges

From: Andrew Ardill <andrew.ardill@gmail.com>
Date: Apr 18, 2016, 07:44 UTC
Message-ID: <CAH5451mDYhavx_OLfXe6cC2WguCsFWEBBBBOCPyX3E6ZJw27+w@mail.gmail.com>
In-Reply-To: <87a8krpehl.fsf@gmail.com>

On 18 April 2016 at 17:23, Christoph Paulik <cpaulik@gmail.com> wrote:

Show 8 quoted lines

> 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