Re: problem when pulling a specific branch from origin

Hi Konstantin,

Thanks for your thorough answer.

Konstantin Khomoutov [off-list ref] wrote:

The first one is that you seem to maintain a wrong idea about what
happens when you do `git pull origin branch`.  It appears you assume
this action is supposed to first update the local branch
"remotes/origin/branch" and then merge it to the locally checked out
branch.  The truth is that specifying a branch in this way to git-pull
(or git-fetch, which is called by git-pull) is a special case -- it
means that no corresponding local ref is updated, and the fetched line
of history is directly merged into the checked out branch right after
fetching (see the git-fetch manual and the EXAMPLES section in the
git-pull manual).

You're right I get the wrong idea of pull origin branch, it's a special
case and it doesn't update local ref.

I'm not really sure about your expectation as you did not clearly
articulate them, so it seems there are two points to touch here...

I expect my local ref to be updated with the server ref.

In your particular case you're merging remote branch "branch" which is
one commit ahead of remote "master" to the locally checked branch
"master" which is, at the moment, the same as the same-named remote
branch.  Consequently, after merging "branch" (which results in
fast-forward) your local branch "master" starts to be one commit ahead
of its remote counterpart; no local branches beyond this one are
updated.

I forgot to checkout the branch in the repository bar, I have attached
the updated script. The result is the same my branch is one commit ahead.

If we run git fetch without argument the refs are updated:

yan:~/tmp/bar$ git fetch
From /home/ivan/tmp/foo
   6fe0a63..ebcae31  branch     -> origin/branch

However running fetch without arguments pull all remote refs which my
developer does not want. Is there a command to update a specific
remote ref?

The second point is less clear/more complicated.
At first, it's not clear whether you wanted to have the remote branch
"branch" become the active local branch during the cloning process, or
"master" (in your case "master" became the active branch).
On the one hand, you explicitly branched "branch" off "master" right
before cloning (updating the first repo's HEAD ref) which hints you
intended that branch to be default in the clone.
On the other hand, while the documentation says the default branch in
the clone is the one listed in the HEAD ref of the source repository, in
my tests using Git (1.7.2.x in Debian and msysgit 1.7.3.x), in cases
like yours the destination repository ends up having the "master" branch
as the default one, not the branch from the HEAD ref; to make this work,
the branch listed in the HEAD ref should have received at least one
commit after forking.  I suspect the problem might be in that such a
branch freshly cloned off "master" points to the same commit object's
name which might confuse Git.
This, in my eyes, might indeed display a bug.

The current behavior is a bit weird to say the least, I don't know if
it's a bug.

Take care,
-- 
Ivan Kanis
http://kanis.fr

At Group L, Stoffel oversees six first-rate programmers, a
managerial challenge roughly comparable to herding cats.
    -- Anonymous , 1985-06-09 , The Washington Post