From: Junio C Hamano <junkio@cox.net>
Date: Fri, 17 Nov 2006 01:31:23 GMT
Subject: Re: [DRAFT] Branching and merging with git
Message-ID: <7v1wo22710.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20061117011319.6738.qmail@science.horizon.com>

linux@horizon.com writes:

> If anyone has any advice on how and why one would invoke git-merge
> directly (the one why I know is to do a >2-way merge), that would
> be appreciated.

I use "git pull . topicA topicB" for a tetrapus, so that is not
a reason for me, but when a topicA's older parts are worthy to
be in 'next' while later parts are not yet, I often do (on 'next'):


	git merge "Merge early part of branch 'topicA'" HEAD topicA~3

Also I used to do

	git merge fast HEAD someTopicIknowIsAFastForward

because it felt faster than "git pull . someTopicIknowisAFastForward"
but I do not do that these days and I would not recommend it to anybody.

>>> 2) Revert changes to a small number of files.
>>>
>>> 	git checkout [<revision>] [--] <paths>
>>>    will copy the version of the <paths> from the index to the working
>>>    directory.  If a <revision> is given, the index for those paths will
>>>    be updated from the given revision before copying from the index to
>>>    the working tree.
>>>
>>>    Unlike the version with no <paths> specified, this does NOT update
>>>    HEAD, even if <paths> is ".".
>> 
>> It's great that you talk correctly about the latest feature-fix
>> that is queued for maint but not yet pushed out.
>
> Um... there's a fix in there?  I thought that's how it always worked.

I do not think naming a directory (say, ".") to mean "revert
everything underneath this directory" worked until the patch I
sent out post 1.4.4 release.

> I also need to mention that if you want to pull a remote tag,
> you need to prefix it with "tags/".

Yes, recent -mm announce message says "git pull ... tag v2.x-mmY".
"tag v2.x-mmy" is a shorthand for "refs/tags/v2.x-mmY:refs/tags/v2.x-mmY"