Re: merge ignores --no-commit in fast-forward case
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Sep 13, 2009, 07:30 UTC
- Message-ID
- <7vocpfz4gm.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <A754ACF1-77C2-4036-A15C-8949E76BD2D5@dbservice.com>
Tomas Carnecky <tom@dbservice.com> writes:
> Bug or feature?
Feature, perhaps a misleading one. As a fast-forward merge does not _create_ a commit, and --no-commit is about not creating a commit, it is logically consistent. But it is not useful nor intuitive to be logically consistent in this case.
Show 6 quoted lines
> 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.