Re: merge ignores --no-commit in fast-forward case

["Björn Steinbrink" <B.Steinbrink@gmx.de>]

On 2009.09.13 00:30:49 -0700, Junio C Hamano wrote:
> Tomas Carnecky <tom@dbservice.com> writes:
> > Three possible solutions that I see:
> >
> >  2) Refuse to do anything if user gives --no-commit and merge is fast- 
> > forward
> >  3) Document this behavior in the manpage
> >  4) Quietly set deny_non_fast_forward when --no-commit was given
> 
> Heh, this is new.  People laugh at me when I number my bullets starting
> from zero, like all good computer scientists do ;-)
> 
> Seriously, we should at least do #3, and as a backward incompatible change
> at least _consider_ doing #2 (I think #4 is merely an implementation detail
> of #2), and if list reaches concensus in favor of such a change, come up
> with a transition plan and do so in the 1.7.0 release.

Hm, I always treated --no-commit as a way of saying: I think this merge
might cause semantic problems, please let me fix those directly, instead
of having to deal with 'commit --amend' and 'diff HEAD^ HEAD'.

Obviously, in case of a fast-forward such semantic problems aren't to be
expected, and I've just been wrong in my expectations. And then I'm
happy with the fast-forward. I'd _not_ be happy if a merge commit would
be forced (that's what #4 was about, right? deny_non_fast_forward only
appears in builtin-receive-pack.c, so I guess allow_fast_forward=0
was meant...).

#2 would be ok with me, I guess. I expected the wrong thing from the
merge, so git may complain, though it means more typing ;-)

Björn