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

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

[Thomas Adam]

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

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

[Jeff King]

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.

-Peff

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

[Thomas Adam]

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

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

[Junio C Hamano]

Thomas Adam <thomas.adam22@gmail.com> writes:

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

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

[Stefan Beller]

On Mon, Mar 21, 2016 at 1:28 PM, Jeff King <peff@peff.net> wrote:
> 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

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

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

[Jeff King]

On Mon, Mar 21, 2016 at 08:43:17PM +0000, Thomas Adam wrote:

> 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

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

[Junio C Hamano]

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

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

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

[Thomas Adam]

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

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

[Jeff King]

On Mon, Mar 21, 2016 at 09:12:18PM +0000, Thomas Adam wrote:

> 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

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

[Thomas Adam]

On 21 March 2016 at 21:18, Jeff King <peff@peff.net> wrote:
> 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.

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

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

[Stefan Beller]

On Mon, Mar 21, 2016 at 2:12 PM, Thomas Adam <thomas.adam22@gmail.com> wrote:
> 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

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

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

[Junio C Hamano]

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?

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

[Stefan Beller]

On Mon, Mar 21, 2016 at 2:57 PM, Junio C Hamano <gitster@pobox.com> wrote:
> 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

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

[Junio C Hamano]

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?  ;-)

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

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

[Stefan Beller]

On Mon, Mar 21, 2016 at 3:42 PM, Junio C Hamano <gitster@pobox.com> wrote:
> 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.

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

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

[Philip Oakley]

From: "Thomas Adam" <thomas.adam22@gmail.com>
Sent: Monday, March 21, 2016 8:43 PM
> 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