Re: [PATCH] core-tutorial: git-merge uses -m for commit messages

From: Junio C Hamano <junkio@cox.net>
Date: Feb 6, 2007, 02:04 UTC
Message-ID: <7v7iuwm48b.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20070205183232.GA9183@moooo.ath.cx>

Matthias Lederhofer <matled@gmx.net> writes:

> Junio C Hamano <junkio@cox.net> wrote:
>> The original examples work perfectly Ok, [..]
> Ah, so the man page is incomplete?

Perhaps, but the older format is not something we would want to recommend to humans, so...

> But without HEAD (git merge -m
> "message" mybranch) the command is ok?

Yes, but ;-).

Humans are encouraged to say "git merge <that-branch>" and let fmt-merge-msg to figure out what message to use.

If I were updating the end-user tutorial, I would probably recommend people to use the newer format that does not force you to say HEAD. core-tutorial however is meant to talk about how Porcelain scripts do things, and in that sense it makes some sense to demonstrate the use of funny "<msg> HEAD <commit>" order, only because it is how git-pull invokes "git merge".

> It seems to work anyway
> because merging HEAD just prints "Already up-to-date with <commit>".

Invoking with -m <msg>, like this:

	git merge -m "$msg" HEAD $commit

it would try to make an octopus that has the current HEAD (this is given always when you are merging), the HEAD you gave from the command line, and the other $commit. The octopus merge strategy is intelligent enough to notice that the second HEAD is the same as the current HEAD so resulting commit would only have two parents. So it may happen to work, but it is never a good practice.