# Aw: Re: [Bug report] 'git status' always says "Your branch is up-to-date with 'origin/master'" 8 messages from 2014-01-06 to 2014-01-14. Participants: Thomas Ackermann, Bryan Turner, Jiang Xin, Jonathan Nieder, Junio C Hamano, Keshav Kini. Thread: https://gitlist.dev/t/35613 ## Thomas Ackermann, 2014-01-06 08:24 Subject: Aw: Re: [Bug report] 'git status' always says "Your branch is up-to-date with 'origin/master'" Message-ID: <1963290835.719443.1388996669450.JavaMail.ngmail@webmail15.arcor-online.net> URL: https://gitlist.dev/e/1963290835.719443.1388996669450.JavaMail.ngmail%40webmail15.arcor-online.net ``` Hi Jiang, this happens with all of my repo clones (I am using V1.8.5.2 on Windows and on Linux). Steps to reproduce: mkdir repo_a && cd repo_a && git init . echo "1">foo && git add foo && git commit -m "1" cd .. git clone repo_a repo_b cd repo_a echo "2">foo && git add foo && git commit -m "2" cd ../repo_b git status git checkout -b "branch" git checkout master 'git status' and 'git checkout master' in repo_b are now reporting "Your branch is up-to-date with 'origin/master'" which is obviously wrong. --- Thomas ----- Original Nachricht ---- Von: Jiang Xin An: Thomas Ackermann Datum: 06.01.2014 06:31 Betreff: Re: [Bug report] 'git status' always says "Your branch is up-to-date with 'origin/master'" > 2014/1/5 Thomas Ackermann : > > Since f223459 "status: always show tracking branch even no change" > > 'git status' (and 'git checkout master' always says > > "Your branch is up-to-date with 'origin/master'" > > even if 'origin/master' is way ahead from local 'master'. > > Hi, Thomas > > Can you provide your operations so that I can reproduce this issue? > > In the commit you mentioned above, there was a new test case named > 'checkout (up-to-date with upstream)' added in 't6040'. I also add two > test-cases locally in order to reproduce the issue you report, and run > them in arbitrary orders, but they all look fine: > > ok 4 - checkout (behind upstream) > ok 5 - checkout (ahead upstream) > ok 6 - checkout (diverged from upstream) > ok 7 - checkout with local tracked branch > ok 8 - checkout (upstream is gone) > ok 9 - checkout (up-to-date with upstream) > ok 10 - checkout (upstream is gone) > ok 11 - checkout with local tracked branch > ok 12 - checkout (diverged from upstream) > ok 13 - checkout (ahead upstream) > ok 14 - checkout (behind upstream) > ok 15 - checkout (diverged from upstream) > ok 16 - checkout (upstream is gone) > ok 17 - checkout (ahead upstream) > ok 18 - checkout with local tracked branch > ok 19 - checkout (behind upstream) > > > The two additional test cases I used locally are: > > checkout_test1() { > test_expect_success 'checkout (behind upstream)' ' > ( > cd test && git checkout b3 > ) >actual && > test_i18ngrep "is behind .* by 1 commit, and can be > fast-forwarded" actual > ' > } > > checkout_test_2() { > test_expect_success 'checkout (ahead upstream)' ' > ( > cd test && git checkout b4 > ) >actual && > test_i18ngrep "is ahead of .* by 2 commits" actual > ' > } > > -- > Jiang Xin > --- Thomas ``` ## Bryan Turner, 2014-01-06 08:48 Subject: Re: Re: [Bug report] 'git status' always says "Your branch is up-to-date with 'origin/master'" Message-ID: URL: https://gitlist.dev/e/CAGyf7-FX1sPjwvKdxeEXopffFPiftgDRqoe7NRWyM1Cm%3D5n6Sw%40mail.gmail.com In-Reply-To: <1963290835.719443.1388996669450.JavaMail.ngmail@webmail15.arcor-online.net> ``` On 6 January 2014 01:24, Thomas Ackermann wrote: > > > Hi Jiang, > > this happens with all of my repo clones (I am using V1.8.5.2 > on Windows and on Linux). Steps to reproduce: > > mkdir repo_a && cd repo_a && git init . > echo "1">foo && git add foo && git commit -m "1" > cd .. > git clone repo_a repo_b > cd repo_a > echo "2">foo && git add foo && git commit -m "2" > cd ../repo_b > git status > git checkout -b "branch" > git checkout master > > 'git status' and 'git checkout master' in repo_b are now > reporting "Your branch is up-to-date with 'origin/master'" > which is obviously wrong. > Unfortunately that's not true. In repo_b your ref for origin/master has not moved. It has remotely (meaning refs/heads/master in repo_a has moved), but git status is not hitting the remote to find out; it only looks at the local state. To see what I mean, run git fetch in repo_b. Once you do that, you'll see that git status correctly reports you're behind. > > --- > Thomas > > ----- Original Nachricht ---- > Von: Jiang Xin > An: Thomas Ackermann > Datum: 06.01.2014 06:31 > Betreff: Re: [Bug report] 'git status' always says "Your branch is up-to-date > with 'origin/master'" > > > 2014/1/5 Thomas Ackermann : > > > Since f223459 "status: always show tracking branch even no change" > > > 'git status' (and 'git checkout master' always says > > > "Your branch is up-to-date with 'origin/master'" > > > even if 'origin/master' is way ahead from local 'master'. > > > > Hi, Thomas > > > > Can you provide your operations so that I can reproduce this issue? > > > > In the commit you mentioned above, there was a new test case named > > 'checkout (up-to-date with upstream)' added in 't6040'. I also add two > > test-cases locally in order to reproduce the issue you report, and run > > them in arbitrary orders, but they all look fine: > > > > ok 4 - checkout (behind upstream) > > ok 5 - checkout (ahead upstream) > > ok 6 - checkout (diverged from upstream) > > ok 7 - checkout with local tracked branch > > ok 8 - checkout (upstream is gone) > > ok 9 - checkout (up-to-date with upstream) > > ok 10 - checkout (upstream is gone) > > ok 11 - checkout with local tracked branch > > ok 12 - checkout (diverged from upstream) > > ok 13 - checkout (ahead upstream) > > ok 14 - checkout (behind upstream) > > ok 15 - checkout (diverged from upstream) > > ok 16 - checkout (upstream is gone) > > ok 17 - checkout (ahead upstream) > > ok 18 - checkout with local tracked branch > > ok 19 - checkout (behind upstream) > > > > > > The two additional test cases I used locally are: > > > > checkout_test1() { > > test_expect_success 'checkout (behind upstream)' ' > > ( > > cd test && git checkout b3 > > ) >actual && > > test_i18ngrep "is behind .* by 1 commit, and can be > > fast-forwarded" actual > > ' > > } > > > > checkout_test_2() { > > test_expect_success 'checkout (ahead upstream)' ' > > ( > > cd test && git checkout b4 > > ) >actual && > > test_i18ngrep "is ahead of .* by 2 commits" actual > > ' > > } > > > > -- > > Jiang Xin > > > > --- > Thomas > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ``` ## Jiang Xin, 2014-01-06 09:04 Subject: Re: Re: [Bug report] 'git status' always says "Your branch is up-to-date with 'origin/master'" Message-ID: URL: https://gitlist.dev/e/CANYiYbH46EiS5iCEzGOi58Kgr%2BaCz_67vHsvRu%3DxSfuYUxosRg%40mail.gmail.com In-Reply-To: <1963290835.719443.1388996669450.JavaMail.ngmail@webmail15.arcor-online.net> ``` 2014/1/6 Thomas Ackermann : > > Hi Jiang, > > this happens with all of my repo clones (I am using V1.8.5.2 > on Windows and on Linux). Steps to reproduce: > > mkdir repo_a && cd repo_a && git init . > echo "1">foo && git add foo && git commit -m "1" > cd .. > git clone repo_a repo_b > cd repo_a > echo "2">foo && git add foo && git commit -m "2" > cd ../repo_b > git status > git checkout -b "branch" Oops. Do git fetch then git checkout master You will get what you want. > git checkout master > > 'git status' and 'git checkout master' in repo_b are now > reporting "Your branch is up-to-date with 'origin/master'" > which is obviously wrong. > -- Jiang Xin ``` ## Thomas Ackermann, 2014-01-06 09:08 Subject: Aw: Re: Re: [Bug report] 'git status' always says "Your branch is up-to-date with 'origin/master'" Message-ID: <1283978462.720554.1388999328222.JavaMail.ngmail@webmail15.arcor-online.net> URL: https://gitlist.dev/e/1283978462.720554.1388999328222.JavaMail.ngmail%40webmail15.arcor-online.net In-Reply-To: ``` > > Unfortunately that's not true. In repo_b your ref for origin/master > has not moved. It has remotely (meaning refs/heads/master in repo_a > has moved), but git status is not hitting the remote to find out; it > only looks at the local state. To see what I mean, run git fetch in > repo_b. Once you do that, you'll see that git status correctly reports > you're behind. > OK; my expectation was, that the remote is checked for this ... I see that this feature is useful for all non-trivial use cases where you have several branches beside master for which the remotes will be updated by git fetch. But for the simple use case where you only have a master branch I consider it not really helpful and - at least for me - misleading. --- Thomas ``` ## Jonathan Nieder, 2014-01-06 15:45 Subject: Re: Re: Re: [Bug report] 'git status' always says "Your branch is up-to-date with 'origin/master'" Message-ID: <20140106154552.GA22189@google.com> URL: https://gitlist.dev/e/20140106154552.GA22189%40google.com In-Reply-To: <1283978462.720554.1388999328222.JavaMail.ngmail@webmail15.arcor-online.net> ``` Hi, Thomas Ackermann wrote: >> In repo_b your ref for origin/master >> has not moved. It has remotely (meaning refs/heads/master in repo_a >> has moved), but git status is not hitting the remote to find out; it >> only looks at the local state. [...] > But for the simple use case where you only have a master > branch I consider it not really helpful and - at least for me - > misleading. I see what you mean, and you're not the only one. Git follows a rule of "never contact another machine unless explicitly asked to using a command such as 'git pull' or 'git fetch'". To support this, it makes a distinction between (1) the remote-tracking ref origin/master and (2) the actual branch "master" in the remote repository. The former is what is updated by 'git fetch', and the latter is something git does not know about without talking to the remote server. What documentation did you use when first starting to learn git? Perhaps it can be fixed to emphasize the distinction between (1) and (2) earlier. Thanks, Jonathan ``` ## Thomas Ackermann, 2014-01-06 16:00 Subject: Aw: Re: Re: Re: [Bug report] 'git status' always says "Your branch is up-to-date with 'origin/master'" Message-ID: <1067660482.1596252.1389024023072.JavaMail.ngmail@webmail11.arcor-online.net> URL: https://gitlist.dev/e/1067660482.1596252.1389024023072.JavaMail.ngmail%40webmail11.arcor-online.net In-Reply-To: <20140106154552.GA22189@google.com> ``` > > But for the simple use case where you only have a master > > branch I consider it not really helpful and - at least for me - > > misleading. > > I see what you mean, and you're not the only one. > > Git follows a rule of "never contact another machine unless explicitly > asked to using a command such as 'git pull' or 'git fetch'". To > support this, it makes a distinction between (1) the remote-tracking > ref origin/master and (2) the actual branch "master" in the remote > repository. The former is what is updated by 'git fetch', and the > latter is something git does not know about without talking to the > remote server. > > What documentation did you use when first starting to learn git? > Perhaps it can be fixed to emphasize the distinction between (1) and > (2) earlier. I think it's not the problem of the documentation but of myself not having it read thorough enough ;-) (This new feature in V1.8.5 of course is not documented in any of the books up to now but in the future could be used to explain the above mentioned rule.) Thanks to you, Bryan and Jiang for your help! --- Thomas ``` ## Junio C Hamano, 2014-01-06 17:12 Subject: Re: Aw: Re: Re: Re: [Bug report] 'git status' always says "Your branch is up-to-date with 'origin/master'" Message-ID: URL: https://gitlist.dev/e/xmqqlhytjapb.fsf%40gitster.dls.corp.google.com In-Reply-To: <1067660482.1596252.1389024023072.JavaMail.ngmail@webmail11.arcor-online.net> ``` Thomas Ackermann writes: > >> > But for the simple use case where you only have a master >> > branch I consider it not really helpful and - at least for me - >> > misleading. >> >> I see what you mean, and you're not the only one. >> >> Git follows a rule of "never contact another machine unless explicitly >> asked to using a command such as 'git pull' or 'git fetch'". To >> support this, it makes a distinction between (1) the remote-tracking >> ref origin/master and (2) the actual branch "master" in the remote >> repository. The former is what is updated by 'git fetch', and the >> latter is something git does not know about without talking to the >> remote server. >> >> What documentation did you use when first starting to learn git? >> Perhaps it can be fixed to emphasize the distinction between (1) and >> (2) earlier. > > I think it's not the problem of the documentation but of myself > not having it read thorough enough ;-) > > (This new feature in V1.8.5 of course is not documented in any of the books > up to now but in the future could be used to explain the above mentioned > rule.) By the way, this is nothing new in 1.8.5; we didn't bother saying up-to-date before, so you may not have noticed, but its silence was already telling you that your branch was up-to-date with respect to what you are building on top of. > > Thanks to you, Bryan and Jiang for your help! > > --- > Thomas ``` ## Keshav Kini, 2014-01-14 23:34 Subject: Re: Aw: Re: Re: Re: [Bug report] 'git status' always says "Your branch is up-to-date with 'origin/master'" Message-ID: <87lhyi6su0.fsf@gmail.com> URL: https://gitlist.dev/e/87lhyi6su0.fsf%40gmail.com In-Reply-To: ``` The following message is a courtesy copy of an article that has been posted to gmane.comp.version-control.git as well. Junio C Hamano writes: > Thomas Ackermann writes: >>> > But for the simple use case where you only have a master >>> > branch I consider it not really helpful and - at least for me - >>> > misleading. >>> >>> I see what you mean, and you're not the only one. >>> >>> Git follows a rule of "never contact another machine unless explicitly >>> asked to using a command such as 'git pull' or 'git fetch'". To >>> support this, it makes a distinction between (1) the remote-tracking >>> ref origin/master and (2) the actual branch "master" in the remote >>> repository. The former is what is updated by 'git fetch', and the >>> latter is something git does not know about without talking to the >>> remote server. >>> >>> What documentation did you use when first starting to learn git? >>> Perhaps it can be fixed to emphasize the distinction between (1) and >>> (2) earlier. >> >> I think it's not the problem of the documentation but of myself >> not having it read thorough enough ;-) >> >> (This new feature in V1.8.5 of course is not documented in any of the books >> up to now but in the future could be used to explain the above mentioned >> rule.) > > By the way, this is nothing new in 1.8.5; we didn't bother saying > up-to-date before, so you may not have noticed, but its silence was > already telling you that your branch was up-to-date with respect to > what you are building on top of. Maybe it would be worthwhile to add a message like "(last fetched from upstream branch at [date])", taken from $GIT_DIR/logs/refs/remotes/foo/bar ? This would mitigate the confusion Thomas suffered, I think. Caveat: pretty ill-defined, since 1) if you've been pushing and not fetching, the most recent time at which it is known that your remote-tracking branch was up to date could be much newer than when it was technically "last fetched"; 2) the upstream branch might not even be a remote-tracking branch; 3) probably something else I haven't thought of. -Keshav ```