Re: Aw: Re: Re: Re: [Bug report] 'git status' always says Your branch is up-to-date with 'origin/master'
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 gits...@pobox.com writes: Thomas Ackermann th.ac...@arcor.de 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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re: [Bug report] 'git status' always says Your branch is up-to-date with 'origin/master'
On 6 January 2014 01:24, Thomas Ackermann th.ac...@arcor.de 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 1foo git add foo git commit -m 1 cd .. git clone repo_a repo_b cd repo_a echo 2foo 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 worldhello@gmail.com An: Thomas Ackermann th.ac...@arcor.de 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 th.ac...@arcor.de: 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re: [Bug report] 'git status' always says Your branch is up-to-date with 'origin/master'
2014/1/6 Thomas Ackermann th.ac...@arcor.de: 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 1foo git add foo git commit -m 1 cd .. git clone repo_a repo_b cd repo_a echo 2foo 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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Aw: Re: Re: [Bug report] 'git status' always says Your branch is up-to-date with 'origin/master'
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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re: Re: [Bug report] 'git status' always says Your branch is up-to-date with 'origin/master'
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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Aw: Re: Re: Re: [Bug report] 'git status' always says Your branch is up-to-date with 'origin/master'
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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html