Subject: Re: problem when pulling a specific branch from origin

From: Ivan Kanis <[email-masked]>
Date: Wed, 02 Feb 2011 10:54:34 +0100

Hi Konstantin,

Thanks for your thorough answer.

Konstantin Khomoutov <[email-masked]> 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