linux@xxxxxxxxxxx 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" - 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