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/<symbolic name>.
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
