On 2009.09.13 00:30:49 -0700, Junio C Hamano wrote: > Tomas Carnecky <tom@xxxxxxxxxxxxx> 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 -- 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