problem when pulling a specific branch from origin

problem when pulling a specific branch from origin

[Ivan Kanis]

Hello,

When I pull a specific branch from a repository I get in a state where
git thinks I am ahead of the branch by one commit. The use case is a
programmer that doesn't want to pull all the branches of the server.

I have made a small script to reproduce the problem:

----
#!/bin/sh

rm -rf foo bar
git --version
mkdir foo
cd foo
git init
echo foo > foo.txt
git add foo.txt
git commit -am"foo"
git checkout -b branch
cd ..
git clone foo bar
cd foo
echo bar > foo.txt
git commit -am"bar"
cd ..
cd bar
git pull origin branch
git status
git branch -rv
----

I get the following output:

----
git version 1.7.3.5
Initialized empty Git repository in /home/ivan/tmp/foo/.git/
[master (root-commit) eefa065] foo
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 foo.txt
Switched to a new branch 'branch'
Cloning into bar...
done.
[branch 7ecd065] bar
 1 files changed, 1 insertions(+), 1 deletions(-)
remote: Counting objects: 5, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From /home/ivan/tmp/foo
 * branch            branch     -> FETCH_HEAD
Updating eefa065..7ecd065
Fast-forward
 foo.txt |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
#
nothing to commit (working directory clean)
  origin/HEAD   -> origin/master
  origin/branch eefa065 foo
  origin/master eefa065 foo
----

I expected to not be ahead of origin/master and that origin/branch
points to 7ecd065. Is this a bug? 

Take care,
-- 
Ivan Kanis

Sure, ninety percent of science fiction is crud. That's because ninety
percent of everything is crud.
    -- Theodore Sturgeon 

Re: problem when pulling a specific branch from origin

[Konstantin Khomoutov]

On Tue, Feb 01, 2011 at 06:25:55PM +0100, Ivan Kanis wrote:

> When I pull a specific branch from a repository I get in a state where
> git thinks I am ahead of the branch by one commit. The use case is a
> programmer that doesn't want to pull all the branches of the server.
> 
> I have made a small script to reproduce the problem:
> 
> ----
> #!/bin/sh
> 
> rm -rf foo bar
> git --version
> mkdir foo
> cd foo
> git init
> echo foo > foo.txt
> git add foo.txt
> git commit -am"foo"
> git checkout -b branch
> cd ..
> git clone foo bar
> cd foo
> echo bar > foo.txt
> git commit -am"bar"
> cd ..
> cd bar
> git pull origin branch
> git status
> git branch -rv
> ----
> 
> I get the following output:
> 
> ----
> git version 1.7.3.5
> Initialized empty Git repository in /home/ivan/tmp/foo/.git/
> [master (root-commit) eefa065] foo
>  1 files changed, 1 insertions(+), 0 deletions(-)
>  create mode 100644 foo.txt
> Switched to a new branch 'branch'
> Cloning into bar...
> done.
> [branch 7ecd065] bar
>  1 files changed, 1 insertions(+), 1 deletions(-)
> remote: Counting objects: 5, done.
> remote: Total 3 (delta 0), reused 0 (delta 0)
> Unpacking objects: 100% (3/3), done.
> From /home/ivan/tmp/foo
>  * branch            branch     -> FETCH_HEAD
> Updating eefa065..7ecd065
> Fast-forward
>  foo.txt |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> # On branch master
> # Your branch is ahead of 'origin/master' by 1 commit.
> #
> nothing to commit (working directory clean)
>   origin/HEAD   -> origin/master
>   origin/branch eefa065 foo
>   origin/master eefa065 foo
> ----
> 
> I expected to not be ahead of origin/master and that origin/branch
> points to 7ecd065. Is this a bug? 

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...

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).
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.

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.

Re: problem when pulling a specific branch from origin

[Ivan Kanis]

[-- Attachment #1: Type: text/plain, Size: 3355 bytes --]

Hi Konstantin,

Thanks for your thorough answer.

Konstantin Khomoutov <flatworm@users.sourceforge.net> 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 

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: repro.sh --]
[-- Type: text/x-sh, Size: 296 bytes --]

#!/bin/sh

rm -rf foo bar
git --version
mkdir foo
cd foo
git init
echo foo > foo.txt
git add foo.txt
git commit -am"foo"
git checkout -b branch
cd ..
git clone foo bar
cd foo
echo bar > foo.txt
git commit -am"bar"
cd ..
cd bar
git checkout branch
git pull origin branch
git status
git branch -rv