Bill Lear  writes:
> 2) Why does git pull do the right thing when on master, but seemingly

quoted text
> changes behavior when on topic?

Because you told it to.
      %  cat .git/remotes/origin

      URL: /repos/git/project

      Pull: refs/heads/master:refs/heads/origin

      Pull: refs/heads/topic:refs/heads/topic
It tells "git pull" to drive "git fetch" to copy their master to

your origin and overwrite your topic with their topic, and then

merge their master to whatever branch you are currently on.
The sane/safe thing to do in the traditional layout (I'll talk

about non-traditional one in a second) is:
 - do your 'pull' only and always while on your 'master' and not

   anywhere else.
 - never build on a branch that appears on the RHS of ':'.
This layout is convenient when you always do fetches and pulls

while on 'master', but has burned enough people.  So what people

on the list seem to recommend is to use a separate remote layout

in the repository.
The principle is:
 * The branches you work on in the repository are kept in refs/heads/
 * Copies of branches from other repositories (it does not

   matter who is in control of them -- some of them may be your

   repository) are kept in refs/remotes/.
So the current "git clone" (if you are using 1.4.4 series, you

can say "git clone --use-separate-remote") creates something

like this instead:
      URL: /repos/git/project

      Pull: refs/heads/master:refs/remotes/origin/master

      Pull: refs/heads/topic:refs/remotes/origin/topic
(git-clone from 1.5.0 does not actually make remotes/origin file

in .git/ that has the above -- it creates the moral equivalent

in .git/config).
So whatever you do the first step of "git pull", which is "git

fetch", will _not_ overwrite the current branch.
In order to prevent merging their 'master' into your 'topic'

when you are on 'topic', git-fetch/git-pull from 1.5.0 uses

further safety which is left by 'git clone'.  The real

configuration created by 'git clone' looks like this:
	[remote "origin"]

        	url = /repos/git/project

                fetch = refs/heads/*:refs/remotes/origin/*

	[branch "master"]

        	remote = origin

                merge = refs/heads/master
The 'fetch' lines correspond to 'Pull' in .git/remotes/origin file;

it uses globbing pattern so if there are new branches on the

remote side you can automatically track them, which is a plus.
But more importantly, when 'fetch' lines only do the globbing

pattern, 'git pull' without explicitly saying which remote

branch you want to merge to the current branch (perhaps by

mistake) refuses to do a merge, if there is no branch.*.merge

configuration ("refs/heads/master" in the above example).  So

with the above configuration, 'git pull' from 1.5.0 will fetch

two remote branches and keep them in remotes/origin/master and

remotes/origin/topic, and if you are on 'master' their

refs/heads/master is merged into your current branch, but if you

are on 'topic', it will not do the merge step (this only applies

to "git pull" without any refspec parameters).
With 1.4.4 series, I think you can create the [branch] section

yourself and do something like this:
	[remote "origin"]

        	url = /repos/git/project

                fetch = refs/heads/master:refs/remotes/origin/master

                fetch = refs/heads/topic:refs/remotes/origin/topic

	[branch "master"]

        	remote = origin

                merge = refs/heads/master

	[branch "topic"]

        	remote = origin

                merge = refs/heads/topic
This configuration also works with 1.5.0, so if you are happy

with this (I am assuming you are using 1.4.4 series, preferably

the last one, 1.4.4.4), after you upgrade to 1.5.0, it will

continue to do its thing (but you would want to upgrade the

fetch line).
-

To unsubscribe from this list: send the line "unsubscribe git" in

the body of a message to majordomo@vger.kernel.org

More majordomo info at  http://vger.kernel.org/majordomo-info.html