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

[Christoph Paulik <cpaulik@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2223 bytes --]


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. 

Regards,
Christoph 
 

Andrew Ardill writes:

> On 18 April 2016 at 16:26, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>>
>> > The command only works as expected when also adding the 
>> > --no-ff flag.
>>
>> Then you need to fix your expectations ;-)
>
> 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


-- 

-------------------------------------------------------
Christoph Paulik
Twitter, Github: @cpaulik
PGP: 8CFC D7DF 2867 B2DC 749B  1B0A 6E3B A262 5186 A0AC

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]