Re: [DRAFT] Branching and merging with git
- From
Junio C Hamano <junkio@cox.net>
- Date
- Nov 17, 2006, 01:31 UTC
- 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.
Show 15 quoted lines
>>> 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"