Re: [DRAFT] Branching and merging with git

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.

quoted

quoted

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"