{"thread":{"id":"35613","subject":"Aw: Re: [Bug report] 'git status' always says \"Your branch is up-to-date with 'origin/master'\"","startedAt":"2014-01-06T08:24:29Z","lastAt":"2014-01-14T23:34:31Z","messageCount":8,"participants":["Thomas Ackermann","Bryan Turner","Jiang Xin","Jonathan Nieder","Junio C Hamano","Keshav Kini"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"232690","messageId":"1963290835.719443.1388996669450.JavaMail.ngmail@webmail15.arcor-online.net","threadId":"35613","inReplyTo":null,"subject":"Aw: Re: [Bug report] 'git status' always says \"Your branch is up-to-date with 'origin/master'\"","fromName":"Thomas Ackermann","fromEmail":"th.acker@arcor.de","sentAt":"2014-01-06T08:24:29Z","receivedAt":"2014-01-06T08:24:29Z","isPatch":false,"sender":{"key":"th.acker@arcor.de","avatar":"https://avatars.githubusercontent.com/u/1358536?v=4"},"body":" \nHi Jiang,\n\nthis happens with all of my repo clones (I am using V1.8.5.2\non Windows and on Linux). Steps to reproduce:\n\nmkdir repo_a && cd repo_a && git init .\necho \"1\">foo && git add foo && git commit -m \"1\"\ncd ..\ngit clone repo_a repo_b\ncd repo_a\necho \"2\">foo && git add foo && git commit -m \"2\"\ncd ../repo_b\ngit status\ngit checkout -b \"branch\"\ngit checkout master\n\n'git status' and 'git checkout master' in repo_b are now \nreporting \"Your branch is up-to-date with 'origin/master'\"\nwhich is obviously wrong.\n\n---\nThomas\n\n----- Original Nachricht ----\nVon:     Jiang Xin <worldhello.net@gmail.com>\nAn:      Thomas Ackermann <th.acker@arcor.de>\nDatum:   06.01.2014 06:31\nBetreff: Re: [Bug report] 'git status' always says \"Your branch is up-to-date\n with 'origin/master'\"\n\n> 2014/1/5 Thomas Ackermann <th.acker@arcor.de>:\n> > Since f223459 \"status: always show tracking branch even no change\"\n> > 'git status' (and 'git checkout master' always says\n> > \"Your branch is up-to-date with 'origin/master'\"\n> > even if 'origin/master' is way ahead from local 'master'.\n> \n> Hi, Thomas\n> \n> Can you provide your operations so that I can reproduce this issue?\n> \n> In the commit you mentioned above, there was a new test case named\n> 'checkout (up-to-date with upstream)' added in 't6040'. I also add two\n> test-cases locally in order to reproduce the issue you report, and run\n> them in arbitrary orders, but they all look fine:\n> \n>     ok 4 - checkout (behind upstream)\n>     ok 5 - checkout (ahead upstream)\n>     ok 6 - checkout (diverged from upstream)\n>     ok 7 - checkout with local tracked branch\n>     ok 8 - checkout (upstream is gone)\n>     ok 9 - checkout (up-to-date with upstream)\n>     ok 10 - checkout (upstream is gone)\n>     ok 11 - checkout with local tracked branch\n>     ok 12 - checkout (diverged from upstream)\n>     ok 13 - checkout (ahead upstream)\n>     ok 14 - checkout (behind upstream)\n>     ok 15 - checkout (diverged from upstream)\n>     ok 16 - checkout (upstream is gone)\n>     ok 17 - checkout (ahead upstream)\n>     ok 18 - checkout with local tracked branch\n>     ok 19 - checkout (behind upstream)\n> \n> \n> The two additional test cases I used locally are:\n> \n>     checkout_test1() {\n>     test_expect_success 'checkout (behind upstream)' '\n>             (\n>                     cd test && git checkout b3\n>             ) >actual &&\n>             test_i18ngrep \"is behind .* by 1 commit, and can be\n> fast-forwarded\" actual\n>     '\n>     }\n> \n>     checkout_test_2() {\n>     test_expect_success 'checkout (ahead upstream)' '\n>             (\n>                     cd test && git checkout b4\n>             ) >actual &&\n>             test_i18ngrep \"is ahead of .* by 2 commits\" actual\n>     '\n>     }\n> \n> -- \n> Jiang Xin\n> \n\n---\nThomas\n"},{"id":"232691","messageId":"CAGyf7-FX1sPjwvKdxeEXopffFPiftgDRqoe7NRWyM1Cm=5n6Sw@mail.gmail.com","threadId":"35613","inReplyTo":"1963290835.719443.1388996669450.JavaMail.ngmail@webmail15.arcor-online.net","subject":"Re: Re: [Bug report] 'git status' always says \"Your branch is up-to-date with 'origin/master'\"","fromName":"Bryan Turner","fromEmail":"bturner@atlassian.com","sentAt":"2014-01-06T08:48:49Z","receivedAt":"2014-01-06T08:48:49Z","isPatch":false,"sender":{"key":"bturner@atlassian.com","avatar":"https://gravatar.com/avatar/16bcf3167981c1ef7c804e502642366d888a35b0d0b0a4ca01fdc442aa1acb1e?d=mp&s=160"},"body":"On 6 January 2014 01:24, Thomas Ackermann <th.acker@arcor.de> wrote:\n>\n>\n> Hi Jiang,\n>\n> this happens with all of my repo clones (I am using V1.8.5.2\n> on Windows and on Linux). Steps to reproduce:\n>\n> mkdir repo_a && cd repo_a && git init .\n> echo \"1\">foo && git add foo && git commit -m \"1\"\n> cd ..\n> git clone repo_a repo_b\n> cd repo_a\n> echo \"2\">foo && git add foo && git commit -m \"2\"\n> cd ../repo_b\n> git status\n> git checkout -b \"branch\"\n> git checkout master\n>\n> 'git status' and 'git checkout master' in repo_b are now\n> reporting \"Your branch is up-to-date with 'origin/master'\"\n> which is obviously wrong.\n>\n\nUnfortunately that's not true. In repo_b your ref for origin/master\nhas not moved. It has remotely (meaning refs/heads/master in repo_a\nhas moved), but git status is not hitting the remote to find out; it\nonly looks at the local state. To see what I mean, run git fetch in\nrepo_b. Once you do that, you'll see that git status correctly reports\nyou're behind.\n\n>\n> ---\n> Thomas\n>\n> ----- Original Nachricht ----\n> Von:     Jiang Xin <worldhello.net@gmail.com>\n> An:      Thomas Ackermann <th.acker@arcor.de>\n> Datum:   06.01.2014 06:31\n> Betreff: Re: [Bug report] 'git status' always says \"Your branch is up-to-date\n>  with 'origin/master'\"\n>\n> > 2014/1/5 Thomas Ackermann <th.acker@arcor.de>:\n> > > Since f223459 \"status: always show tracking branch even no change\"\n> > > 'git status' (and 'git checkout master' always says\n> > > \"Your branch is up-to-date with 'origin/master'\"\n> > > even if 'origin/master' is way ahead from local 'master'.\n> >\n> > Hi, Thomas\n> >\n> > Can you provide your operations so that I can reproduce this issue?\n> >\n> > In the commit you mentioned above, there was a new test case named\n> > 'checkout (up-to-date with upstream)' added in 't6040'. I also add two\n> > test-cases locally in order to reproduce the issue you report, and run\n> > them in arbitrary orders, but they all look fine:\n> >\n> >     ok 4 - checkout (behind upstream)\n> >     ok 5 - checkout (ahead upstream)\n> >     ok 6 - checkout (diverged from upstream)\n> >     ok 7 - checkout with local tracked branch\n> >     ok 8 - checkout (upstream is gone)\n> >     ok 9 - checkout (up-to-date with upstream)\n> >     ok 10 - checkout (upstream is gone)\n> >     ok 11 - checkout with local tracked branch\n> >     ok 12 - checkout (diverged from upstream)\n> >     ok 13 - checkout (ahead upstream)\n> >     ok 14 - checkout (behind upstream)\n> >     ok 15 - checkout (diverged from upstream)\n> >     ok 16 - checkout (upstream is gone)\n> >     ok 17 - checkout (ahead upstream)\n> >     ok 18 - checkout with local tracked branch\n> >     ok 19 - checkout (behind upstream)\n> >\n> >\n> > The two additional test cases I used locally are:\n> >\n> >     checkout_test1() {\n> >     test_expect_success 'checkout (behind upstream)' '\n> >             (\n> >                     cd test && git checkout b3\n> >             ) >actual &&\n> >             test_i18ngrep \"is behind .* by 1 commit, and can be\n> > fast-forwarded\" actual\n> >     '\n> >     }\n> >\n> >     checkout_test_2() {\n> >     test_expect_success 'checkout (ahead upstream)' '\n> >             (\n> >                     cd test && git checkout b4\n> >             ) >actual &&\n> >             test_i18ngrep \"is ahead of .* by 2 commits\" actual\n> >     '\n> >     }\n> >\n> > --\n> > Jiang Xin\n> >\n>\n> ---\n> Thomas\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n"},{"id":"232692","messageId":"CANYiYbH46EiS5iCEzGOi58Kgr+aCz_67vHsvRu=xSfuYUxosRg@mail.gmail.com","threadId":"35613","inReplyTo":"1963290835.719443.1388996669450.JavaMail.ngmail@webmail15.arcor-online.net","subject":"Re: Re: [Bug report] 'git status' always says \"Your branch is up-to-date with 'origin/master'\"","fromName":"Jiang Xin","fromEmail":"worldhello.net@gmail.com","sentAt":"2014-01-06T09:04:47Z","receivedAt":"2014-01-06T09:04:47Z","isPatch":false,"sender":{"key":"worldhello.net@gmail.com","avatar":"https://avatars.githubusercontent.com/u/183860?v=4"},"body":"2014/1/6 Thomas Ackermann <th.acker@arcor.de>:\n>\n> Hi Jiang,\n>\n> this happens with all of my repo clones (I am using V1.8.5.2\n> on Windows and on Linux). Steps to reproduce:\n>\n> mkdir repo_a && cd repo_a && git init .\n> echo \"1\">foo && git add foo && git commit -m \"1\"\n> cd ..\n> git clone repo_a repo_b\n> cd repo_a\n> echo \"2\">foo && git add foo && git commit -m \"2\"\n> cd ../repo_b\n> git status\n> git checkout -b \"branch\"\n\nOops. Do\n\n    git fetch\n\nthen\n\n    git checkout master\n\nYou will get what you want.\n\n> git checkout master\n>\n> 'git status' and 'git checkout master' in repo_b are now\n> reporting \"Your branch is up-to-date with 'origin/master'\"\n> which is obviously wrong.\n>\n\n--\nJiang Xin\n"},{"id":"232693","messageId":"1283978462.720554.1388999328222.JavaMail.ngmail@webmail15.arcor-online.net","threadId":"35613","inReplyTo":"CAGyf7-FX1sPjwvKdxeEXopffFPiftgDRqoe7NRWyM1Cm=5n6Sw@mail.gmail.com","subject":"Aw: Re: Re: [Bug report] 'git status' always says \"Your branch is up-to-date with 'origin/master'\"","fromName":"Thomas Ackermann","fromEmail":"th.acker@arcor.de","sentAt":"2014-01-06T09:08:48Z","receivedAt":"2014-01-06T09:08:48Z","isPatch":false,"sender":{"key":"th.acker@arcor.de","avatar":"https://avatars.githubusercontent.com/u/1358536?v=4"},"body":" \n> \n> Unfortunately that's not true. In repo_b your ref for origin/master\n> has not moved. It has remotely (meaning refs/heads/master in repo_a\n> has moved), but git status is not hitting the remote to find out; it\n> only looks at the local state. To see what I mean, run git fetch in\n> repo_b. Once you do that, you'll see that git status correctly reports\n> you're behind.\n> \n\nOK; my expectation was, that the remote is checked for this ...\nI see that this feature is useful for all non-trivial use cases\nwhere you have several branches beside master for which the\nremotes will be updated by git fetch.\nBut for the simple use case where you only have a master\nbranch I consider it not really helpful and - at least for me -\nmisleading.\n\n---\nThomas\n"},{"id":"232718","messageId":"20140106154552.GA22189@google.com","threadId":"35613","inReplyTo":"1283978462.720554.1388999328222.JavaMail.ngmail@webmail15.arcor-online.net","subject":"Re: Re: Re: [Bug report] 'git status' always says \"Your branch is up-to-date with 'origin/master'\"","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2014-01-06T15:45:52Z","receivedAt":"2014-01-06T15:45:52Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nThomas Ackermann wrote:\n\n>>                                In repo_b your ref for origin/master\n>> has not moved. It has remotely (meaning refs/heads/master in repo_a\n>> has moved), but git status is not hitting the remote to find out; it\n>> only looks at the local state.\n[...]\n> But for the simple use case where you only have a master\n> branch I consider it not really helpful and - at least for me -\n> misleading.\n\nI see what you mean, and you're not the only one.\n\nGit follows a rule of \"never contact another machine unless explicitly\nasked to using a command such as 'git pull' or 'git fetch'\".  To\nsupport this, it makes a distinction between (1) the remote-tracking\nref origin/master and (2) the actual branch \"master\" in the remote\nrepository.  The former is what is updated by 'git fetch', and the\nlatter is something git does not know about without talking to the\nremote server.\n\nWhat documentation did you use when first starting to learn git?\nPerhaps it can be fixed to emphasize the distinction between (1) and\n(2) earlier.\n\nThanks,\nJonathan\n"},{"id":"232721","messageId":"1067660482.1596252.1389024023072.JavaMail.ngmail@webmail11.arcor-online.net","threadId":"35613","inReplyTo":"20140106154552.GA22189@google.com","subject":"Aw: Re: Re: Re: [Bug report] 'git status' always says \"Your branch is up-to-date with 'origin/master'\"","fromName":"Thomas Ackermann","fromEmail":"th.acker@arcor.de","sentAt":"2014-01-06T16:00:23Z","receivedAt":"2014-01-06T16:00:23Z","isPatch":false,"sender":{"key":"th.acker@arcor.de","avatar":"https://avatars.githubusercontent.com/u/1358536?v=4"},"body":" \n> > But for the simple use case where you only have a master\n> > branch I consider it not really helpful and - at least for me -\n> > misleading.\n> \n> I see what you mean, and you're not the only one.\n> \n> Git follows a rule of \"never contact another machine unless explicitly\n> asked to using a command such as 'git pull' or 'git fetch'\".  To\n> support this, it makes a distinction between (1) the remote-tracking\n> ref origin/master and (2) the actual branch \"master\" in the remote\n> repository.  The former is what is updated by 'git fetch', and the\n> latter is something git does not know about without talking to the\n> remote server.\n> \n> What documentation did you use when first starting to learn git?\n> Perhaps it can be fixed to emphasize the distinction between (1) and\n> (2) earlier.\n\nI think it's not the problem of the documentation but of myself\nnot having it read thorough enough ;-)\n\n(This new feature in V1.8.5 of course is not documented in any of the books\nup to now but in the future could be used to explain the above mentioned\nrule.)\n\nThanks to you, Bryan and Jiang for your help!\n\n---\nThomas\n"},{"id":"232729","messageId":"xmqqlhytjapb.fsf@gitster.dls.corp.google.com","threadId":"35613","inReplyTo":"1067660482.1596252.1389024023072.JavaMail.ngmail@webmail11.arcor-online.net","subject":"Re: Aw: Re: Re: Re: [Bug report] 'git status' always says \"Your branch is up-to-date with 'origin/master'\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-01-06T17:12:48Z","receivedAt":"2014-01-06T17:12:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Ackermann <th.acker@arcor.de> writes:\n\n>  \n>> > But for the simple use case where you only have a master\n>> > branch I consider it not really helpful and - at least for me -\n>> > misleading.\n>> \n>> I see what you mean, and you're not the only one.\n>> \n>> Git follows a rule of \"never contact another machine unless explicitly\n>> asked to using a command such as 'git pull' or 'git fetch'\".  To\n>> support this, it makes a distinction between (1) the remote-tracking\n>> ref origin/master and (2) the actual branch \"master\" in the remote\n>> repository.  The former is what is updated by 'git fetch', and the\n>> latter is something git does not know about without talking to the\n>> remote server.\n>> \n>> What documentation did you use when first starting to learn git?\n>> Perhaps it can be fixed to emphasize the distinction between (1) and\n>> (2) earlier.\n>\n> I think it's not the problem of the documentation but of myself\n> not having it read thorough enough ;-)\n>\n> (This new feature in V1.8.5 of course is not documented in any of the books\n> up to now but in the future could be used to explain the above mentioned\n> rule.)\n\nBy the way, this is nothing new in 1.8.5; we didn't bother saying\nup-to-date before, so you may not have noticed, but its silence was\nalready telling you that your branch was up-to-date with respect to\nwhat you are building on top of.\n\n>\n> Thanks to you, Bryan and Jiang for your help!\n>\n> ---\n> Thomas\n"},{"id":"233114","messageId":"87lhyi6su0.fsf@gmail.com","threadId":"35613","inReplyTo":"xmqqlhytjapb.fsf@gitster.dls.corp.google.com","subject":"Re: Aw: Re: Re: Re: [Bug report] 'git status' always says \"Your branch is up-to-date with 'origin/master'\"","fromName":"Keshav Kini","fromEmail":"keshav.kini@gmail.com","sentAt":"2014-01-14T23:34:31Z","receivedAt":"2014-01-14T23:34:31Z","isPatch":false,"sender":{"key":"keshav.kini@gmail.com","avatar":"https://avatars.githubusercontent.com/u/691290?v=4"},"body":"The following message is a courtesy copy of an article\nthat has been posted to gmane.comp.version-control.git as well.\n\nJunio C Hamano <gitster@pobox.com> writes:\n> Thomas Ackermann <th.acker@arcor.de> writes:\n>>> > But for the simple use case where you only have a master\n>>> > branch I consider it not really helpful and - at least for me -\n>>> > misleading.\n>>> \n>>> I see what you mean, and you're not the only one.\n>>> \n>>> Git follows a rule of \"never contact another machine unless explicitly\n>>> asked to using a command such as 'git pull' or 'git fetch'\".  To\n>>> support this, it makes a distinction between (1) the remote-tracking\n>>> ref origin/master and (2) the actual branch \"master\" in the remote\n>>> repository.  The former is what is updated by 'git fetch', and the\n>>> latter is something git does not know about without talking to the\n>>> remote server.\n>>> \n>>> What documentation did you use when first starting to learn git?\n>>> Perhaps it can be fixed to emphasize the distinction between (1) and\n>>> (2) earlier.\n>>\n>> I think it's not the problem of the documentation but of myself\n>> not having it read thorough enough ;-)\n>>\n>> (This new feature in V1.8.5 of course is not documented in any of the books\n>> up to now but in the future could be used to explain the above mentioned\n>> rule.)\n>\n> By the way, this is nothing new in 1.8.5; we didn't bother saying\n> up-to-date before, so you may not have noticed, but its silence was\n> already telling you that your branch was up-to-date with respect to\n> what you are building on top of.\n\nMaybe it would be worthwhile to add a message like \"(last fetched from\nupstream branch at [date])\", taken from\n$GIT_DIR/logs/refs/remotes/foo/bar ?  This would mitigate the confusion\nThomas suffered, I think.\n\nCaveat: pretty ill-defined, since 1) if you've been pushing and not\nfetching, the most recent time at which it is known that your\nremote-tracking branch was up to date could be much newer than when it\nwas technically \"last fetched\"; 2) the upstream branch might not\neven be a remote-tracking branch; 3) probably something else I haven't\nthought of.\n\n-Keshav\n"}]}