{"thread":{"id":"26381","subject":"problem when pulling a specific branch from origin","startedAt":"2011-02-01T17:25:55Z","lastAt":"2011-02-02T09:54:34Z","messageCount":3,"participants":["Ivan Kanis","Konstantin Khomoutov"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"160196","messageId":"877hdjy8d8.fsf@kanis.fr","threadId":"26381","inReplyTo":null,"subject":"problem when pulling a specific branch from origin","fromName":"Ivan Kanis","fromEmail":"expire-by-2011-02-06@kanis.fr","sentAt":"2011-02-01T17:25:55Z","receivedAt":"2011-02-01T17:25:55Z","isPatch":false,"sender":{"key":"expire-by-2011-02-06@kanis.fr","avatar":null},"body":"Hello,\n\nWhen I pull a specific branch from a repository I get in a state where\ngit thinks I am ahead of the branch by one commit. The use case is a\nprogrammer that doesn't want to pull all the branches of the server.\n\nI have made a small script to reproduce the problem:\n\n----\n#!/bin/sh\n\nrm -rf foo bar\ngit --version\nmkdir foo\ncd foo\ngit init\necho foo > foo.txt\ngit add foo.txt\ngit commit -am\"foo\"\ngit checkout -b branch\ncd ..\ngit clone foo bar\ncd foo\necho bar > foo.txt\ngit commit -am\"bar\"\ncd ..\ncd bar\ngit pull origin branch\ngit status\ngit branch -rv\n----\n\nI get the following output:\n\n----\ngit version 1.7.3.5\nInitialized empty Git repository in /home/ivan/tmp/foo/.git/\n[master (root-commit) eefa065] foo\n 1 files changed, 1 insertions(+), 0 deletions(-)\n create mode 100644 foo.txt\nSwitched to a new branch 'branch'\nCloning into bar...\ndone.\n[branch 7ecd065] bar\n 1 files changed, 1 insertions(+), 1 deletions(-)\nremote: Counting objects: 5, done.\nremote: Total 3 (delta 0), reused 0 (delta 0)\nUnpacking objects: 100% (3/3), done.\nFrom /home/ivan/tmp/foo\n * branch            branch     -> FETCH_HEAD\nUpdating eefa065..7ecd065\nFast-forward\n foo.txt |    2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n# On branch master\n# Your branch is ahead of 'origin/master' by 1 commit.\n#\nnothing to commit (working directory clean)\n  origin/HEAD   -> origin/master\n  origin/branch eefa065 foo\n  origin/master eefa065 foo\n----\n\nI expected to not be ahead of origin/master and that origin/branch\npoints to 7ecd065. Is this a bug? \n\nTake care,\n-- \nIvan Kanis\n\nSure, ninety percent of science fiction is crud. That's because ninety\npercent of everything is crud.\n    -- Theodore Sturgeon \n"},{"id":"160242","messageId":"20110202001734.GL5713@localhost.localdomain","threadId":"26381","inReplyTo":"877hdjy8d8.fsf@kanis.fr","subject":"Re: problem when pulling a specific branch from origin","fromName":"Konstantin Khomoutov","fromEmail":"flatworm@users.sourceforge.net","sentAt":"2011-02-02T00:17:34Z","receivedAt":"2011-02-02T00:17:34Z","isPatch":false,"sender":{"key":"flatworm@users.sourceforge.net","avatar":null},"body":"On Tue, Feb 01, 2011 at 06:25:55PM +0100, Ivan Kanis wrote:\n\n> When I pull a specific branch from a repository I get in a state where\n> git thinks I am ahead of the branch by one commit. The use case is a\n> programmer that doesn't want to pull all the branches of the server.\n> \n> I have made a small script to reproduce the problem:\n> \n> ----\n> #!/bin/sh\n> \n> rm -rf foo bar\n> git --version\n> mkdir foo\n> cd foo\n> git init\n> echo foo > foo.txt\n> git add foo.txt\n> git commit -am\"foo\"\n> git checkout -b branch\n> cd ..\n> git clone foo bar\n> cd foo\n> echo bar > foo.txt\n> git commit -am\"bar\"\n> cd ..\n> cd bar\n> git pull origin branch\n> git status\n> git branch -rv\n> ----\n> \n> I get the following output:\n> \n> ----\n> git version 1.7.3.5\n> Initialized empty Git repository in /home/ivan/tmp/foo/.git/\n> [master (root-commit) eefa065] foo\n>  1 files changed, 1 insertions(+), 0 deletions(-)\n>  create mode 100644 foo.txt\n> Switched to a new branch 'branch'\n> Cloning into bar...\n> done.\n> [branch 7ecd065] bar\n>  1 files changed, 1 insertions(+), 1 deletions(-)\n> remote: Counting objects: 5, done.\n> remote: Total 3 (delta 0), reused 0 (delta 0)\n> Unpacking objects: 100% (3/3), done.\n> From /home/ivan/tmp/foo\n>  * branch            branch     -> FETCH_HEAD\n> Updating eefa065..7ecd065\n> Fast-forward\n>  foo.txt |    2 +-\n>  1 files changed, 1 insertions(+), 1 deletions(-)\n> # On branch master\n> # Your branch is ahead of 'origin/master' by 1 commit.\n> #\n> nothing to commit (working directory clean)\n>   origin/HEAD   -> origin/master\n>   origin/branch eefa065 foo\n>   origin/master eefa065 foo\n> ----\n> \n> I expected to not be ahead of origin/master and that origin/branch\n> points to 7ecd065. Is this a bug? \n\nI'm not really sure about your expectation as you did not clearly\narticulate them, so it seems there are two points to touch here...\n\nThe first one is that you seem to maintain a wrong idea about what\nhappens when you do `git pull origin branch`.  It appears you assume\nthis action is supposed to first update the local branch\n\"remotes/origin/branch\" and then merge it to the locally checked out\nbranch.  The truth is that specifying a branch in this way to git-pull\n(or git-fetch, which is called by git-pull) is a special case -- it\nmeans that no corresponding local ref is updated, and the fetched line\nof history is directly merged into the checked out branch right after\nfetching (see the git-fetch manual and the EXAMPLES section in the\ngit-pull manual).\nIn your particular case you're merging remote branch \"branch\" which is\none commit ahead of remote \"master\" to the locally checked branch\n\"master\" which is, at the moment, the same as the same-named remote\nbranch.  Consequently, after merging \"branch\" (which results in\nfast-forward) your local branch \"master\" starts to be one commit ahead\nof its remote counterpart; no local branches beyond this one are\nupdated.\n\nThe second point is less clear/more complicated.\nAt first, it's not clear whether you wanted to have the remote branch\n\"branch\" become the active local branch during the cloning process, or\n\"master\" (in your case \"master\" became the active branch).\nOn the one hand, you explicitly branched \"branch\" off \"master\" right\nbefore cloning (updating the first repo's HEAD ref) which hints you\nintended that branch to be default in the clone.\nOn the other hand, while the documentation says the default branch in\nthe clone is the one listed in the HEAD ref of the source repository, in\nmy tests using Git (1.7.2.x in Debian and msysgit 1.7.3.x), in cases\nlike yours the destination repository ends up having the \"master\" branch\nas the default one, not the branch from the HEAD ref; to make this work,\nthe branch listed in the HEAD ref should have received at least one\ncommit after forking.  I suspect the problem might be in that such a\nbranch freshly cloned off \"master\" points to the same commit object's\nname which might confuse Git.\nThis, in my eyes, might indeed display a bug.\n"},{"id":"160261","messageId":"87d3naiwx1.fsf@kanis.fr","threadId":"26381","inReplyTo":"20110202001734.GL5713@localhost.localdomain","subject":"Re: problem when pulling a specific branch from origin","fromName":"Ivan Kanis","fromEmail":"expire-by-2011-02-07@kanis.fr","sentAt":"2011-02-02T09:54:34Z","receivedAt":"2011-02-02T09:54:34Z","isPatch":false,"sender":{"key":"expire-by-2011-02-07@kanis.fr","avatar":null},"body":"Hi Konstantin,\n\nThanks for your thorough answer.\n\nKonstantin Khomoutov <flatworm@users.sourceforge.net> wrote:\n\n> The first one is that you seem to maintain a wrong idea about what\n> happens when you do `git pull origin branch`.  It appears you assume\n> this action is supposed to first update the local branch\n> \"remotes/origin/branch\" and then merge it to the locally checked out\n> branch.  The truth is that specifying a branch in this way to git-pull\n> (or git-fetch, which is called by git-pull) is a special case -- it\n> means that no corresponding local ref is updated, and the fetched line\n> of history is directly merged into the checked out branch right after\n> fetching (see the git-fetch manual and the EXAMPLES section in the\n> git-pull manual).\n\nYou're right I get the wrong idea of pull origin branch, it's a special\ncase and it doesn't update local ref.\n\n> I'm not really sure about your expectation as you did not clearly\n> articulate them, so it seems there are two points to touch here...\n\nI expect my local ref to be updated with the server ref.\n\n> In your particular case you're merging remote branch \"branch\" which is\n> one commit ahead of remote \"master\" to the locally checked branch\n> \"master\" which is, at the moment, the same as the same-named remote\n> branch.  Consequently, after merging \"branch\" (which results in\n> fast-forward) your local branch \"master\" starts to be one commit ahead\n> of its remote counterpart; no local branches beyond this one are\n> updated.\n\nI forgot to checkout the branch in the repository bar, I have attached\nthe updated script. The result is the same my branch is one commit ahead.\n\nIf we run git fetch without argument the refs are updated:\n\nyan:~/tmp/bar$ git fetch\nFrom /home/ivan/tmp/foo\n   6fe0a63..ebcae31  branch     -> origin/branch\n\nHowever running fetch without arguments pull all remote refs which my\ndeveloper does not want. Is there a command to update a specific\nremote ref?\n\n> The second point is less clear/more complicated.\n> At first, it's not clear whether you wanted to have the remote branch\n> \"branch\" become the active local branch during the cloning process, or\n> \"master\" (in your case \"master\" became the active branch).\n> On the one hand, you explicitly branched \"branch\" off \"master\" right\n> before cloning (updating the first repo's HEAD ref) which hints you\n> intended that branch to be default in the clone.\n> On the other hand, while the documentation says the default branch in\n> the clone is the one listed in the HEAD ref of the source repository, in\n> my tests using Git (1.7.2.x in Debian and msysgit 1.7.3.x), in cases\n> like yours the destination repository ends up having the \"master\" branch\n> as the default one, not the branch from the HEAD ref; to make this work,\n> the branch listed in the HEAD ref should have received at least one\n> commit after forking.  I suspect the problem might be in that such a\n> branch freshly cloned off \"master\" points to the same commit object's\n> name which might confuse Git.\n> This, in my eyes, might indeed display a bug.\n\nThe current behavior is a bit weird to say the least, I don't know if\nit's a bug.\n\nTake care,\n-- \nIvan Kanis\nhttp://kanis.fr\n\nAt Group L, Stoffel oversees six first-rate programmers, a\nmanagerial challenge roughly comparable to herding cats.\n    -- Anonymous , 1985-06-09 , The Washington Post \n\n\n#!/bin/sh\n\nrm -rf foo bar\ngit --version\nmkdir foo\ncd foo\ngit init\necho foo > foo.txt\ngit add foo.txt\ngit commit -am\"foo\"\ngit checkout -b branch\ncd ..\ngit clone foo bar\ncd foo\necho bar > foo.txt\ngit commit -am\"bar\"\ncd ..\ncd bar\ngit checkout branch\ngit pull origin branch\ngit status\ngit branch -rv\n"}]}