Re: merge ignores --no-commit in fast-forward case
- From
Björn Steinbrink <b.steinbrink@gmx.de>
- Date
- Sep 19, 2009, 08:09 UTC
- Message-ID
- <20090919080903.GA16316@atjola.homenet>
- In-Reply-To
- <7vocpfz4gm.fsf@alter.siamese.dyndns.org>
On 2009.09.13 00:30:49 -0700, Junio C Hamano wrote:
Show 15 quoted lines
> 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