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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Matthias Lederhofer <matled@xxxxxxx> writes:

> Junio C Hamano <junkio@xxxxxxx> 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.

-
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]