Aw: Re: [Bug report] 'git status' always says "Your branch is up-to-date with 'origin/master'"

> 2014/1/5 Thomas Ackermann <th.acker@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
> 

>
>
> 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 <worldhello.net@gmail.com>
> An:      Thomas Ackermann <th.acker@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.acker@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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

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

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

> Thomas Ackermann <th.acker@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.

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