threads / discuss / 41772

When does git check for branch-X being uptodate with origin/branch-X?

Subject: When does git check for branch-X being uptodate with origin/branch-X?

## tl;dr

16 messages between Mar 21, 2016 and Mar 22, 2016.

replies: 15people: 5as markdown or json

Thomas Adam· Mar 21, 2016, 20:21 UTC · lore
Hi all,

Something I've seen a few times of late (although I doubt that's any indication that the code has changed in Git) is the reporting of branch-X being uptodate with origin/branch-X when it isn't.

When does git check to see if branch-X has a remote tracking branch and that it has changes on it? Only, the output below is misleading:

% git checkout master Switched to branch 'master' Your branch is up-to-date with 'fvwmorg/master'.

[fvwm-cvs-to-git/docs]{10345}[0][master] % git pull
remote: Counting objects: 26, done.
remote: Compressing objects: 100% (12/12), done.
remote: Total 26 (delta 18), reused 22 (delta 14), pack-reused 0
Unpacking objects: 100% (26/26), done.
From github.com:fvwmorg/fvwm
   c029868..36cc898  master     -> fvwmorg/master
   4f0c7ec..36cc898  ta/git-docs -> fvwmorg/ta/git-docs
Updating c029868..36cc898
Fast-forward
[...]

Clearly, it's obvious that "Your branch is up-to-date with 'fvwmorg/master'." is misleading. Note that in this case, there's no passwords or other hindrances to Git being able to work out that a branch is behind another.

Any light that can be shed on this, is much appreciated!

Kindly, Thomas Adam

Jeff King· Mar 21, 2016, 20:28 UTC · re: Thomas Adam · lore

Re: When does git check for branch-X being uptodate with origin/branch-X?

On Mon, Mar 21, 2016 at 08:21:46PM +0000, Thomas Adam wrote:
Show 27 quoted lines
> Something I've seen a few times of late (although I doubt that's any
> indication that the code has changed in Git) is the reporting of
> branch-X being uptodate with origin/branch-X when it isn't.
> 
> When does git check to see if branch-X has a remote tracking branch
> and that it has changes on it?  Only, the output below is misleading:
> 
> % git checkout master
> Switched to branch 'master'
> Your branch is up-to-date with 'fvwmorg/master'.
> 
> [fvwm-cvs-to-git/docs]{10345}[0][master] % git pull
> remote: Counting objects: 26, done.
> remote: Compressing objects: 100% (12/12), done.
> remote: Total 26 (delta 18), reused 22 (delta 14), pack-reused 0
> Unpacking objects: 100% (26/26), done.
> From github.com:fvwmorg/fvwm
>    c029868..36cc898  master     -> fvwmorg/master
>    4f0c7ec..36cc898  ta/git-docs -> fvwmorg/ta/git-docs
> Updating c029868..36cc898
> Fast-forward
> [...]
> 
> Clearly, it's obvious that "Your branch is up-to-date with
> 'fvwmorg/master'." is misleading.  Note that in this case, there's no
> passwords or other hindrances to Git being able to work out that a
> branch is behind another.

The message from checking is looking only at your local refs/remotes/fvwmorg/master branch, which is essentially a cache of what is in the actual remote repository.

We never contact other repositories unless explicitly asked to by fetch, pull, push, etc. If you want to have the most up-to-date value without merging, you can just "git fetch" to update the tracking branches.

-Peff
Thomas Adam· Mar 21, 2016, 20:43 UTC · re: Jeff King · lore

Re: When does git check for branch-X being uptodate with origin/branch-X?

On 21 March 2016 at 20:28, Jeff King <peff@peff.net> wrote:
> We never contact other repositories unless explicitly asked to by
> fetch, pull, push, etc. If you want to have the most up-to-date value
> without merging, you can just "git fetch" to update the tracking
> branches.

Thanks. I understand how to use git-fetch, it's more a case of whether even printing that message is useful? I appreciate it can only go on the cached value, but it is still misleading to print that in the case where the cache might not be up to date. Of course, determining that is a different problem.

-- Thomas Adam
Junio C Hamano· Mar 21, 2016, 20:47 UTC · re: Thomas Adam · lore

Re: When does git check for branch-X being uptodate with origin/branch-X?

Thomas Adam <thomas.adam22@gmail.com> writes:
Show 10 quoted lines
> On 21 March 2016 at 20:28, Jeff King <peff@peff.net> wrote:
>> We never contact other repositories unless explicitly asked to by
>> fetch, pull, push, etc. If you want to have the most up-to-date value
>> without merging, you can just "git fetch" to update the tracking
>> branches.
>
> Thanks.  I understand how to use git-fetch, it's more a case of
> whether even printing that message is useful?  I appreciate it can
> only go on the cached value, but it is still misleading to print that
> in the case where the cache might not be up to date.

The real value of that message is "you haven't done anything on top of what you last fetched from there", so "you are up-to-date" may indeed be confusing, but I do not think of a better phrasing (other than spelling out "last fetched from there" part explicitly, which is quite a mouthful).

Jeff King· Mar 21, 2016, 20:50 UTC · re: Thomas Adam · lore

Re: When does git check for branch-X being uptodate with origin/branch-X?

On Mon, Mar 21, 2016 at 08:43:17PM +0000, Thomas Adam wrote:
Show 11 quoted lines
> On 21 March 2016 at 20:28, Jeff King <peff@peff.net> wrote:
> > We never contact other repositories unless explicitly asked to by
> > fetch, pull, push, etc. If you want to have the most up-to-date value
> > without merging, you can just "git fetch" to update the tracking
> > branches.
> 
> Thanks.  I understand how to use git-fetch, it's more a case of
> whether even printing that message is useful?  I appreciate it can
> only go on the cached value, but it is still misleading to print that
> in the case where the cache might not be up to date.  Of course,
> determining that is a different problem.

I don't think it is limited to this particular message. _Any_ operation that uses the tracking branches is going to potentially be out of date with respect to what has happened on a remote server (so any time you look at @{upstream}, or do a "rebase" without an arguments, etc).

Those things are useful, even if your local tracking branch may not reflect the latest value on the server. If there is anything to fix, IMHO, it is for the documentation to make more clear the mental model of the workflow of "fetch separately, then all other operations are disconnected".

But that's just my opinion. Did you have some specific change you're interested in? I don't think removing that message is productive; it _is_ useful information. Perhaps it could be more clear that we are talking about the tracking branch?

-Peff
Thomas Adam· Mar 21, 2016, 21:12 UTC · re: Jeff King · lore

Re: When does git check for branch-X being uptodate with origin/branch-X?

On 21 March 2016 at 20:50, Jeff King <peff@peff.net> wrote:
> But that's just my opinion. Did you have some specific change you're
> interested in? I don't think removing that message is productive; it
> _is_ useful information. Perhaps it could be more clear that we are
> talking about the tracking branch?

I don't have a specific change in mind per-se, rather than to discuss how we might be able to improve the error message, or document somewhere that it's referring to the tracking branch. Maybe that's the point--is it worth mentioning the time/date of when the cache was last updated? That is:

"branch-X is uptodate with origin/branch-X (as of DD-MM-YY HH:MM:SS)"

No one's suggesting that this message is removed, I'm not sure where you got that from?

-- Thomas Adam
Jeff King· Mar 21, 2016, 21:18 UTC · re: Thomas Adam · lore

Re: When does git check for branch-X being uptodate with origin/branch-X?

On Mon, Mar 21, 2016 at 09:12:18PM +0000, Thomas Adam wrote:
Show 13 quoted lines
> On 21 March 2016 at 20:50, Jeff King <peff@peff.net> wrote:
> > But that's just my opinion. Did you have some specific change you're
> > interested in? I don't think removing that message is productive; it
> > _is_ useful information. Perhaps it could be more clear that we are
> > talking about the tracking branch?
> 
> I don't have a specific change in mind per-se, rather than to discuss
> how we might be able to improve the error message, or document
> somewhere that it's referring to the tracking branch.  Maybe that's
> the point--is it worth mentioning the time/date of when the cache was
> last updated?  That is:
> 
> "branch-X is uptodate with origin/branch-X (as of DD-MM-YY HH:MM:SS)"

Again, just my opinion, but that looks awfully clunky. And it doesn't address the other messages (you might be behind origin/branch-X by N commits, or ahead by N, but only as of that particular date). Do we want to annotate every message whose value was computed based on a tracking branch?

> No one's suggesting that this message is removed, I'm not sure where
> you got that from?
You said earlier:
> [...]it's more a case of whether even printing that message is useful?

I didn't know quite what you had in mind, which is why I asked. If we all agree that removing it is a bad idea, then good, we don't have to bother discussing that option. :)

-Peff
Thomas Adam· Mar 21, 2016, 21:22 UTC · re: Jeff King · lore

Re: When does git check for branch-X being uptodate with origin/branch-X?

On 21 March 2016 at 21:18, Jeff King <peff@peff.net> wrote:
Show 5 quoted lines
> Again, just my opinion, but that looks awfully clunky. And it doesn't
> address the other messages (you might be behind origin/branch-X by N
> commits, or ahead by N, but only as of that particular date). Do we want
> to annotate every message whose value was computed based on a tracking
> branch?

Hmm. I would hope not. I'll wait for others to make a call on this, but it's about all I can suggest without significantly bloating the message which isn't desirable either.

Show 10 quoted lines
>> No one's suggesting that this message is removed, I'm not sure where
>> you got that from?
>
> You said earlier:
>
>> [...]it's more a case of whether even printing that message is useful?
>
> I didn't know quite what you had in mind, which is why I asked. If we
> all agree that removing it is a bad idea, then good, we don't have to
> bother discussing that option. :)

Ah, oops! I was meaning more, whether to print the message in the case where the branch was uptodate, but now I appreciate it's cached. Apologies for the confusion.

-- Thomas Adam
Stefan Beller· Mar 21, 2016, 21:50 UTC · re: Thomas Adam · lore

Re: When does git check for branch-X being uptodate with origin/branch-X?

On Mon, Mar 21, 2016 at 2:12 PM, Thomas Adam <thomas.adam22@gmail.com> wrote:
Show 13 quoted lines
> On 21 March 2016 at 20:50, Jeff King <peff@peff.net> wrote:
>> But that's just my opinion. Did you have some specific change you're
>> interested in? I don't think removing that message is productive; it
>> _is_ useful information. Perhaps it could be more clear that we are
>> talking about the tracking branch?
>
> I don't have a specific change in mind per-se, rather than to discuss
> how we might be able to improve the error message, or document
> somewhere that it's referring to the tracking branch.  Maybe that's
> the point--is it worth mentioning the time/date of when the cache was
> last updated?  That is:
>
> "branch-X is uptodate with origin/branch-X (as of DD-MM-YY HH:MM:SS)"

Actually I like that feature of recording the last known time we fetched, I would have found that information useful in the past a few times. (unrelated to this exact message, but if we were to make this change, we would need to record the time somewhere, and that's what I would have wanted)

I would think putting the date in this exact spot is a similar level of advice what Eric was proposing earlier today in $gmane/289438 (was: [PATCH][Outreachy] branch -D: allow - as abbreviation of @{-1}, give advice when force deleting a branch on how to recover that branch) So people (specially beginners as this points out more of the inner workings) may find it useful, but some would find it too noisy and rather turn it off.

Stefan
Show 9 quoted lines
>
> No one's suggesting that this message is removed, I'm not sure where
> you got that from?
>
> -- Thomas Adam
> --
> 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
Junio C Hamano· Mar 21, 2016, 21:57 UTC · re: Stefan Beller · lore

Re: When does git check for branch-X being uptodate with origin/branch-X?

Stefan Beller <sbeller@google.com> writes:
Show 7 quoted lines
>> "branch-X is uptodate with origin/branch-X (as of DD-MM-YY HH:MM:SS)"
>
> Actually I like that feature of recording the last known time we fetched,
> I would have found that information useful in the past a few times. (unrelated
> to this exact message, but if we were to make this change, we would
> need to record
> the time somewhere, and that's what I would have wanted)
Like in reflog for refs/remotes/origin/branch-X?
Stefan Beller· Mar 21, 2016, 22:11 UTC · re: Junio C Hamano · lore

Re: When does git check for branch-X being uptodate with origin/branch-X?

On Mon, Mar 21, 2016 at 2:57 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 12 quoted lines
> Stefan Beller <sbeller@google.com> writes:
>
>>> "branch-X is uptodate with origin/branch-X (as of DD-MM-YY HH:MM:SS)"
>>
>> Actually I like that feature of recording the last known time we fetched,
>> I would have found that information useful in the past a few times. (unrelated
>> to this exact message, but if we were to make this change, we would
>> need to record
>> the time somewhere, and that's what I would have wanted)
>
> Like in reflog for refs/remotes/origin/branch-X?
>

Heh, exactly that. Though the git-reflog tool is missing the time as it appears on the reflog file.

Just quoting from my reflog file

$ cat .git/logs/refs/remotes/origin/master f3adf457e046f92f039353762a78dcb3afb2cb13 754884255bb580df159e58defa81cdd30b5c430c Stefan Beller <sbeller@google.com> 1452529563 -0800 fetch --append origin: fast-forward 754884255bb580df159e58defa81cdd30b5c430c fc10eb5b87a75af2cb93a3932897572f2c544915 Stefan Beller <sbeller@google.com> 1452709338 -0800 fetch --append origin: fast-forward fc10eb5b87a75af2cb93a3932897572f2c544915 3ee1e0fe11e2eb617170d0487fccfffc67f2b82b Stefan Beller <sbeller@google.com> 1453411906 -0800 fetch --append origin: fast-forward 3ee1e0fe11e2eb617170d0487fccfffc67f2b82b e572fef9d459497de2bd719747d5625a27c9b41d Stefan Beller <sbeller@google.com> 1453508448 -0800 fetch --append origin: fast-forward e572fef9d459497de2bd719747d5625a27c9b41d d10e2cb9d0299a26f43d57dd5bdcf2b3f86a30b3 Stefan Beller <sbeller@google.com> 1453939673 -0800 fetch --append origin: fast-forward d10e2cb9d0299a26f43d57dd5bdcf2b3f86a30b3 701fa7fe35768fd6e291b667566ac4b434f6e1c9 Stefan Beller <sbeller@google.com> 1454364624 -0800 fetch --append origin: fast-forward 701fa7fe35768fd6e291b667566ac4b434f6e1c9 07c314d22dc8b0a982e76e7498a3f4d384062491 Stefan Beller <sbeller@google.com> 1454445124 -0800 fetch --append origin: fast-forward 07c314d22dc8b0a982e76e7498a3f4d384062491 563e38491eaee6e02643a22c9503d4f774d6c5be Stefan Beller <sbeller@google.com> 1454610734 -0800 fetch --append origin: fast-forward 563e38491eaee6e02643a22c9503d4f774d6c5be ff4ea6004fb48146330d663d64a71e7774f059f9 Stefan Beller <sbeller@google.com> 1455040507 -0800 fetch --append origin: fast-forward ff4ea6004fb48146330d663d64a71e7774f059f9 494398473714dcbedb38b1ac79b531c7384b3bc4 Stefan Beller <sbeller@google.com> 1455150849 -0800 rebase -i (start): checkout origin/master: fast-forward 494398473714dcbedb38b1ac79b531c7384b3bc4 0233b800c838ddda41db318ee396320b3c21a560 Stefan Beller <sbeller@google.com> 1455824915 -0800 fetch --append origin: fast-forward 0233b800c838ddda41db318ee396320b3c21a560 70bd996071bf724a7b151c81a165e8837179d6d7 Stefan Beller <sbeller@google.com> 1456250296 -0800 fetch --append origin: fast-forward 70bd996071bf724a7b151c81a165e8837179d6d7 7c0da37d7b0e09c199788191b322bf45fd003e3c Stefan Beller <sbeller@google.com> 1456337953 -0800 fetch --append origin: fast-forward 7c0da37d7b0e09c199788191b322bf45fd003e3c 56f37fda511e1615dc6df86c68f3b841711a7828 Stefan Beller <sbeller@google.com> 1456358750 -0800 fetch --append origin: fast-forward 56f37fda511e1615dc6df86c68f3b841711a7828 f02fbc4f9433937ee0463d0342d6d7d97e1f6f1e Stefan Beller <sbeller@google.com> 1456530630 -0800 fetch --append origin: fast-forward f02fbc4f9433937ee0463d0342d6d7d97e1f6f1e d285ab0a41c5c04222cf356066d1df1e6096c5a7 Stefan Beller <sbeller@google.com> 1457045695 -0800 fetch --append origin: fast-forward d285ab0a41c5c04222cf356066d1df1e6096c5a7 ab5d01a29eb7380ceab070f0807c2939849c44bc Stefan Beller <sbeller@google.com> 1457133708 -0800 fetch --append origin: fast-forward ab5d01a29eb7380ceab070f0807c2939849c44bc ed9067f705aa51819c7dfff7e4190dd267beaf5d Stefan Beller <sbeller@google.com> 1457652712 -0800 fetch --append origin: fast-forward ed9067f705aa51819c7dfff7e4190dd267beaf5d db6696f653b917509dac1ac13b922e12773a84ff Stefan Beller <sbeller@google.com> 1458061695 -0700 fetch --append origin: fast-forward db6696f653b917509dac1ac13b922e12773a84ff c2c5f6b1e479f2c38e0e01345350620944e3527f Stefan Beller <sbeller@google.com> 1458083837 -0700 fetch --append origin: fast-forward c2c5f6b1e479f2c38e0e01345350620944e3527f d9c691a759d62cef53a6cc11864a2ef4b0829244 Stefan Beller <sbeller@google.com> 1458167761 -0700 fetch --append origin: fast-forward d9c691a759d62cef53a6cc11864a2ef4b0829244 44915db9358936fbad21221fed3abf86166696fd Stefan Beller <sbeller@google.com> 1458255346 -0700 fetch --append origin: fast-forward 44915db9358936fbad21221fed3abf86166696fd b552ff8c67d1b1c60d7d1fcf25a0603a37649b4f Stefan Beller <sbeller@google.com> 1458580955 -0700 fetch --append origin: fast-forward

I do understand the "fetch --append origin fast-forward", (I assume they are coming from regular fetches). But the "rebase -i (start): checkout origin/master: fast-forward" seems to have recorded there in error as I never rebased origin/master itself, but only other stuff on top of origin/master. Why would we have such an entry in there?

Thanks, Stefan

Junio C Hamano· Mar 21, 2016, 22:42 UTC · re: Stefan Beller · lore

Re: When does git check for branch-X being uptodate with origin/branch-X?

Stefan Beller <sbeller@google.com> writes:
Show 10 quoted lines
> On> 494398473714dcbedb38b1ac79b531c7384b3bc4 Stefan Beller
> <sbeller@google.com> 1455150849 -0800 rebase -i (start): checkout
> origin/master: fast-forward
>
> I do understand the "fetch --append origin fast-forward", (I assume
> they are coming from regular fetches). But the "rebase -i (start):
> checkout origin/master: fast-forward" seems to have recorded there in
> error as I never rebased origin/master itself, but only other stuff on
> top of origin/master.
> Why would we have such an entry in there?
You tell us--what did you do back then?  ;-)

It indeed looks strange. You shouldn't be able to check out a remote-tracking branch, so any log for local operation would be in HEAD's reflog, but not in remotes' reflog.

I was curious to see what kind of entries I have and I do not seem to have anything strange.

$ find .git/logs/refs/remotes/ -type f -print0 |
  xargs -0 sed -Ee '
    s/^[0-9a-f]{40} [0-9a-f]{40} [^>]*> [0-9]* [-+][0-9]{4}       //
  ' |
  sort -u
fetch --append l10n: fast-forward
fetch git-gui: fast-forward
fetch -v git-svn: fast-forward
fetch -v paulus: fast-forward
pull git-svn: fast-forward
pull git-svn: forced-update
pull -s subtree paulus: fast-forward
pull -v git-svn ks/svn-pathnameencoding-4: storing head
update by push
Puzzled...
Stefan Beller· Mar 21, 2016, 23:18 UTC · re: Junio C Hamano · lore

Re: When does git check for branch-X being uptodate with origin/branch-X?

On Mon, Mar 21, 2016 at 3:42 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 14 quoted lines
> Stefan Beller <sbeller@google.com> writes:
>
>> On> 494398473714dcbedb38b1ac79b531c7384b3bc4 Stefan Beller
>> <sbeller@google.com> 1455150849 -0800 rebase -i (start): checkout
>> origin/master: fast-forward
>>
>> I do understand the "fetch --append origin fast-forward", (I assume
>> they are coming from regular fetches). But the "rebase -i (start):
>> checkout origin/master: fast-forward" seems to have recorded there in
>> error as I never rebased origin/master itself, but only other stuff on
>> top of origin/master.
>> Why would we have such an entry in there?
>
> You tell us--what did you do back then?  ;-)

I wish I knew, my memories are not as good as a disk. It was Thursday 11th 2016, around 4:30 pm local time. I would assume I exercised Git the "usual" way as always.

This entry doesn't appear in .git/logs/HEAD.
However
    grep -r "rebase -i (start): checkout origin/master: fast-forward"
-- .git/logs
yields
.git/logs/refs/remotes/origin/master
.git/logs/refs/remotes/origin/nd/exclusion-regression-fix
.git/logs/refs/remotes/origin/ew/connect-verbose
.git/logs/refs/remotes/origin/next
.git/logs/refs/remotes/kernelorg/todo
.git/logs/refs/remotes/kernelorg/master
.git/logs/refs/remotes/kernelorg/next
.git/logs/refs/remotes/kernelorg/next

For example I am pretty sure I never touched origin/nd/exclusion-regression-fix and origin/ew/connect-verbose directly myself (i.e. checking them out or anything. The only way I got in contact with them is via "git fetch --all" and the remote side merging these branches into various other branches.

Show 24 quoted lines
>
> It indeed looks strange.  You shouldn't be able to check out a
> remote-tracking branch, so any log for local operation would be in
> HEAD's reflog, but not in remotes' reflog.
>
> I was curious to see what kind of entries I have and I do not seem
> to have anything strange.
>
> $ find .git/logs/refs/remotes/ -type f -print0 |
>   xargs -0 sed -Ee '
>     s/^[0-9a-f]{40} [0-9a-f]{40} [^>]*> [0-9]* [-+][0-9]{4}       //
>   ' |
>   sort -u
> fetch --append l10n: fast-forward
> fetch git-gui: fast-forward
> fetch -v git-svn: fast-forward
> fetch -v paulus: fast-forward
> pull git-svn: fast-forward
> pull git-svn: forced-update
> pull -s subtree paulus: fast-forward
> pull -v git-svn ks/svn-pathnameencoding-4: storing head
> update by push
>
> Puzzled...

doing a similar thing here: $ find .git/logs/refs/remotes/ -type f -print0 | xargs -0 cat |cut -c134-|sort -u fetch --append origin: fast-forward fetch --append origin: forced-update fetch --append origin: storing head [omitting lots of other remotes which also have "fetch --append" lines] rebase -i (start): checkout origin/master: fast-forward rebase -i (start): checkout origin/master: storing head update by push

As I have lots of terminals open, I suspect my confusing workflow doesn't help either, i.e. a normal thing for me is: term1: git rebase -i origin/master term1: <resolve merge conflict, edit patches, etc> term2: git fetch --all term1: continue on <resolve merge conflict, edit patches, etc> term1: actually finish the rebase

I tried reproducing this quickly, but I did not succeed. I'll try to keep an eye on this.

Thanks, Stefan

Philip Oakley· Mar 22, 2016, 19:23 UTC · re: Thomas Adam · lore

Re: When does git check for branch-X being uptodate with origin/branch-X?

From: "Thomas Adam" <thomas.adam22@gmail.com>
Sent: Monday, March 21, 2016 8:43 PM
Show 13 quoted lines
> On 21 March 2016 at 20:28, Jeff King <peff@peff.net> wrote:
>> We never contact other repositories unless explicitly asked to by
>> fetch, pull, push, etc. If you want to have the most up-to-date value
>> without merging, you can just "git fetch" to update the tracking
>> branches.
>
> Thanks.  I understand how to use git-fetch, it's more a case of
> whether even printing that message is useful?  I appreciate it can
> only go on the cached value, but it is still misleading to print that
> in the case where the cache might not be up to date.  Of course,
> determining that is a different problem.
>
> -- Thomas Adam

This issue (that the tracking is passive, not 'active') may also be something for the 'Beginner mode' discussion.

The rtb (remote tracking branch) was something I'd noted earlier in the initial 'Beginner mode', discussion, $gmane/288727/focus=288812 (GSoC Introduction; 14 Mar '16, 22:08)

"The Git data model is very powerful and it does take a lot of 'unlearning' of old expectations (which is very hard) before the capabilities of the git model become well established in the users mind. For example, remote tracking branches are not remote but local, and are a reverse polish description (a local branch which keeps track of a remote's branch, from the last time you looked).

Different people get different parts of the model in different orders and different rates. Identifying the many issues (in model understanding) may be a start for identifying which command/options should be targeted."

-- Philip

Stefan Beller· Mar 21, 2016, 20:48 UTC · re: Jeff King · lore

Re: When does git check for branch-X being uptodate with origin/branch-X?

On Mon, Mar 21, 2016 at 1:28 PM, Jeff King <peff@peff.net> wrote:
Show 38 quoted lines
> On Mon, Mar 21, 2016 at 08:21:46PM +0000, Thomas Adam wrote:
>
>> Something I've seen a few times of late (although I doubt that's any
>> indication that the code has changed in Git) is the reporting of
>> branch-X being uptodate with origin/branch-X when it isn't.
>>
>> When does git check to see if branch-X has a remote tracking branch
>> and that it has changes on it?  Only, the output below is misleading:
>>
>> % git checkout master
>> Switched to branch 'master'
>> Your branch is up-to-date with 'fvwmorg/master'.
>>
>> [fvwm-cvs-to-git/docs]{10345}[0][master] % git pull
>> remote: Counting objects: 26, done.
>> remote: Compressing objects: 100% (12/12), done.
>> remote: Total 26 (delta 18), reused 22 (delta 14), pack-reused 0
>> Unpacking objects: 100% (26/26), done.
>> From github.com:fvwmorg/fvwm
>>    c029868..36cc898  master     -> fvwmorg/master
>>    4f0c7ec..36cc898  ta/git-docs -> fvwmorg/ta/git-docs
>> Updating c029868..36cc898
>> Fast-forward
>> [...]
>>
>> Clearly, it's obvious that "Your branch is up-to-date with
>> 'fvwmorg/master'." is misleading.  Note that in this case, there's no
>> passwords or other hindrances to Git being able to work out that a
>> branch is behind another.
>
> The message from checking is looking only at your local
> refs/remotes/fvwmorg/master branch, which is essentially a cache of what
> is in the actual remote repository.
>
> We never contact other repositories unless explicitly asked to by
> fetch, pull, push, etc. If you want to have the most up-to-date value
> without merging, you can just "git fetch" to update the tracking
> branches.
To elaborate on that:

If you do "git fetch" instead of "git pull" and then followed by "git status" it should tell you something like:

    Your branch is behind 'origin/master' by 73 commits, and can be
fast-forwarded.

The origin/ (or in your case fvwmorg/) is a local "cache" on what we think the remote is at. the remote may change of course.

Stefan
Show 6 quoted lines
>
> -Peff
> --
> 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
Junio C Hamano· Mar 21, 2016, 20:52 UTC · re: Jeff King · lore

Re: When does git check for branch-X being uptodate with origin/branch-X?

Jeff King <peff@peff.net> writes:
> The message from checking is looking only at your local
> refs/remotes/fvwmorg/master branch, which is essentially a cache of what
> is in the actual remote repository.

Saying "cache of what is ..." would further confuse people, I am afraid. We just keep a record of what we last observed and we do not actively go out and update the remote tracking branch without being told by the end user. "cache of what we saw there when we contacted them the last time" is OK ;-).

Show 7 quoted lines
>
> We never contact other repositories unless explicitly asked to by
> fetch, pull, push, etc. If you want to have the most up-to-date value
> without merging, you can just "git fetch" to update the tracking
> branches.
>
> -Peff

← back to recent threads