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

2014-01-14 Thread 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 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'

2014-01-06 Thread Bryan Turner
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-01-06 Thread Jiang Xin
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'

2014-01-06 Thread 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
--
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'

2014-01-06 Thread 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
--
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'

2014-01-06 Thread 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
--
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