Re: git-merge adds test to a message -- bug?

Hallo Johannes,

Johannes Schindelin schrieb am Tue 25. Mar, 21:04 (+0100):

On Tue, 25 Mar 2008, Jörg Sommer wrote:

quoted

Junio C Hamano schrieb am Mon 24. Mar, 09:45 (-0700):

quoted

Johannes Schindelin [off-list ref] writes:

quoted

On Sun, 23 Mar 2008, Junio C Hamano wrote:

quoted

I unfortunately do not recall why _prepend_, and not _replace_, had 
to be the right behaviour.

http://article.gmane.org/gmane.comp.version-control.git/31896/match=git+merge+make+usable

So it was "my suspicion that people who would want to pass -m would 
want it to behave this way".

I do not care deeply either way myself, as I never have found use for 
-m to the merge command, but I think it could have been argued either 
way.

I would like to argue for the replace way. :) Take git rebase -p as an 
example. If a merge is included in the rebase, it's redone with git 
merge -m. Because git rebase works with detached heads you get merge 
messages like this: [...]

That only means that the original author of rebase -p was a lazy bastard 
and did not use the proper way to call git-merge, namely

	git <msg> HEAD <the-other-branch>

It this really a proper way to call git merge? The manpage says:

    The second syntax (<msg> HEAD <remote>) is supported for historical
    reasons. Do not use it from the command line or in new scripts. It is
    the same as git merge -m <msg> <remote>.

And how would you pass the option for the strategy to this form? Git
rebase calls git merge with -s.

Bye, Jörg.
-- 
But in the case of "git revert", it should be an ancestor (or the user
is just insane, in which case it doesn't matter - insane people can do
insane things)
Linus Torvalds [ref]