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

6 messages between Apr 7, 2026 and Apr 8, 2026, from Jesko Schwarzer, Junio C Hamano, Ben Knoble, D. Ben Knoble.

Plain Markdown or JSON for tools and agents.

Jesko SchwarzerApr 7, 2026, 13:10 UTC on lore

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

Junio C HamanoApr 7, 2026, 15:23 UTC in reply to Jesko Schwarzer on lore

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

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.

Ben KnobleApr 7, 2026, 16:13 UTC in reply to Junio C Hamano on lore

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

Show 21 quoted lines

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

Junio C HamanoApr 7, 2026, 16:23 UTC in reply to Ben Knoble on lore

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

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/

Junio C HamanoApr 7, 2026, 16:27 UTC in reply to Junio C Hamano on lore

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

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

Show 9 quoted lines

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

D. Ben KnobleApr 8, 2026, 18:14 UTC in reply to Junio C Hamano on lore

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

On Tue, Apr 7, 2026 at 12:27 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 16 quoted lines

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