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

On 18 April 2016 at 16:26, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

I *think* the core of this problem is that the intent of the end-user does not align with the command options available.

In this use case (as far as I can tell), the user wants to see what the result of a merge from somewhere else will look like, without changing their HEAD.

While you are correct in saying a fast-forward does not create any new commits, for the user it certainly looks like a whole slew of new commits have been added. Moreover, the nature of the option means that the user has to investigate if the merge is a fast-forward in order to know what the outcome of the command will be.

If the merge is a fast-forward, --no-commit has no effect on the outcome. If the merge is not a fast-forward, --no-commit has a huge effect on the outcome.

If I see a --no-commit option, as an inexperienced user, I would be quite surprised to find my HEAD changed after using it. It would be far more intuitive, for that user, for --no-commit to imply --no-ff however I suspect that such a change may well cause more problems then it fixes.

What I wonder is, in what situation is the current behaviour is desirable?

While I agree that the option works as designed, I think its behaviour is more surprising to the end user then it should be.

Regards,

Andrew Ardill