checkout: clarify "up to date with origin/" uses local remote-tracking ref

checkout: clarify "up to date with origin/" uses local remote-tracking ref

[Jesko Schwarzer]

Hello together,

this is my first post. I am using git*version 2.43.0* on Ubuntu 24.04LTS 
and have an UX proposal:

When I run git checkout master on a branch that tracks origin/master, 
Git often prints:

Your branch is up to date with 'origin/master'.

I naively read this as "my branch matches the current state of the 
remote repository." In practice, origin/master here is only the local 
remote-tracking ref; it is not refreshed unless I run fetch/pull. If the 
remote has moved on since my last fetch, the message can still be "up to 
date" while git pull immediately brings new commits (fast-forwarding 
origin/master and then master).
So the comparison is correct relative to the cached 
refs/remotes/origin/master, but the wording is easy to *misread *as "I 
just verified against the server."

Would the project consider one of the following?
     1. *Clearer messaging*, e.g. indicating that the comparison is 
against the last-known origin/<branch> (or similar wording that does not 
imply a live remote check).
     2. *Optional context* when available (e.g. from reflog or last 
fetch time), so users know how stale the origin/* ref might be — if that 
is technically and policy-wise acceptable.

I understand Git deliberately avoids implicit network access on 
checkout; the issue is only that the status text does not make the 
"local remote-tracking ref" semantics obvious to everyone.

Thanks for maintaining Git,
mit freundlichen Grüßen/Best regards
/Jesko

Re: checkout: clarify "up to date with origin/" uses local remote-tracking ref

[Junio C Hamano]

Jesko Schwarzer <jesko@schwarzers.de> writes:

> Would the project consider one of the following?
>      1. *Clearer messaging*, e.g. indicating that the comparison is 
> against the last-known origin/<branch> (or similar wording that does not 
> imply a live remote check).

Surely.  Patches to start discussions are very much welcome.

>      2. *Optional context* when available (e.g. from reflog or last 
> fetch time), so users know how stale the origin/* ref might be — if that 
> is technically and policy-wise acceptable.

I am imagining that #1 above would add something that conveys
"relative to the last known state", and this will extend/replace the
phrase you would choose for "the last known state" with "as of N
days ago" or something when necessary pieces of information is
available, right?  That sounds entirely feasible.

> I understand Git deliberately avoids implicit network access on 
> checkout; the issue is only that the status text does not make the 
> "local remote-tracking ref" semantics obvious to everyone.

Re: checkout: clarify "up to date with origin/" uses local remote-tracking ref

[Ben Knoble]

> 
> Le 7 avr. 2026 à 11:28, Junio C Hamano <gitster@pobox.com> a écrit :
> 
> Jesko Schwarzer <jesko@schwarzers.de> writes:
> 
>> Would the project consider one of the following?
>>     1. *Clearer messaging*, e.g. indicating that the comparison is
>> against the last-known origin/<branch> (or similar wording that does not
>> imply a live remote check).
> 
> Surely.  Patches to start discussions are very much welcome.
> 
>>     2. *Optional context* when available (e.g. from reflog or last
>> fetch time), so users know how stale the origin/* ref might be — if that
>> is technically and policy-wise acceptable.
> 
> I am imagining that #1 above would add something that conveys
> "relative to the last known state", and this will extend/replace the
> phrase you would choose for "the last known state" with "as of N
> days ago" or something when necessary pieces of information is
> available, right?  That sounds entirely feasible.

I seem to recall a recent (last ~6 months) thread about “last fetch time” and there being some question of how to record it. Alas I haven’t searched the archives to find it. 

Re: checkout: clarify "up to date with origin/" uses local remote-tracking ref

[Junio C Hamano]

Ben Knoble <ben.knoble@gmail.com> writes:

> I seem to recall a recent (last ~6 months) thread about “last
> fetch time” and there being some question of how to record
> it. Alas I haven’t searched the archives to find it.

Is it a bit older thread?

    https://lore.kernel.org/git/xmqqh65b2ci3.fsf@gitster.g/

Re: checkout: clarify "up to date with origin/" uses local remote-tracking ref

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Ben Knoble <ben.knoble@gmail.com> writes:
>
>> I seem to recall a recent (last ~6 months) thread about “last
>> fetch time” and there being some question of how to record
>> it. Alas I haven’t searched the archives to find it.
>
> Is it a bit older thread?
>
>     https://lore.kernel.org/git/xmqqh65b2ci3.fsf@gitster.g/

Wrong link.  This one is better.

  https://lore.kernel.org/git/CALnO6CB2TjwRWr0=c2nWY5DnwLeqXiaA5fCiEeF85zivmLggjA@mail.gmail.com/

Re: checkout: clarify "up to date with origin/" uses local remote-tracking ref

[D. Ben Knoble]

On Tue, Apr 7, 2026 at 12:27 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Junio C Hamano <gitster@pobox.com> writes:
>
> > Ben Knoble <ben.knoble@gmail.com> writes:
> >
> >> I seem to recall a recent (last ~6 months) thread about “last
> >> fetch time” and there being some question of how to record
> >> it. Alas I haven’t searched the archives to find it.
> >
> > Is it a bit older thread?
> >
> >     https://lore.kernel.org/git/xmqqh65b2ci3.fsf@gitster.g/
>
> Wrong link.  This one is better.
>
>   https://lore.kernel.org/git/CALnO6CB2TjwRWr0=c2nWY5DnwLeqXiaA5fCiEeF85zivmLggjA@mail.gmail.com/

Yes, I think that thread ended up with some discussion of what
timestamps are available and what are not:

    https://lore.kernel.org/git/xmqqseottxld.fsf@gitster.g/

-- 
D. Ben Knoble