Tomas Carnecky <tom@xxxxxxxxxxxxx> 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. > 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. -- 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