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

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

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

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

[Bryan Turner]

On 6 January 2014 01:24, Thomas Ackermann <th.acker@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 "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 <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

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

[Jiang Xin]

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

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

[Thomas Ackermann]

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

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

[Jonathan Nieder]

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

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

[Thomas Ackermann]

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

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

[Junio C Hamano]

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.

>
> Thanks to you, Bryan and Jiang for your help!
>
> ---
> Thomas

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

[Keshav Kini]

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 <gitster@pobox.com> writes:
> 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.

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