{"thread":{"id":"65450","subject":"checkout: clarify \"up to date with origin/\" uses local remote-tracking ref","startedAt":"2026-04-07T13:16:34Z","lastAt":"2026-04-08T18:14:36Z","messageCount":6,"participants":["Jesko Schwarzer","Junio C Hamano","Ben Knoble","D. Ben Knoble"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"541065","messageId":"956b1bec-99ec-4d28-8229-804eb14e6d3a@schwarzers.de","threadId":"65450","inReplyTo":null,"subject":"checkout: clarify \"up to date with origin/\" uses local remote-tracking ref","fromName":"Jesko Schwarzer","fromEmail":"jesko@schwarzers.de","sentAt":"2026-04-07T13:10:25Z","receivedAt":"2026-04-07T13:16:34Z","isPatch":false,"body":"Hello together,\n\nthis is my first post. I am using git*version 2.43.0* on Ubuntu 24.04LTS \nand have an UX proposal:\n\nWhen I run git checkout master on a branch that tracks origin/master, \nGit often prints:\n\nYour branch is up to date with 'origin/master'.\n\nI naively read this as \"my branch matches the current state of the \nremote repository.\" In practice, origin/master here is only the local \nremote-tracking ref; it is not refreshed unless I run fetch/pull. If the \nremote has moved on since my last fetch, the message can still be \"up to \ndate\" while git pull immediately brings new commits (fast-forwarding \norigin/master and then master).\nSo the comparison is correct relative to the cached \nrefs/remotes/origin/master, but the wording is easy to *misread *as \"I \njust verified against the server.\"\n\nWould the project consider one of the following?\n     1. *Clearer messaging*, e.g. indicating that the comparison is \nagainst the last-known origin/ (or similar wording that does not \nimply a live remote check).\n     2. *Optional context* when available (e.g. from reflog or last \nfetch time), so users know how stale the origin/* ref might be — if that \nis technically and policy-wise acceptable.\n\nI understand Git deliberately avoids implicit network access on \ncheckout; the issue is only that the status text does not make the \n\"local remote-tracking ref\" semantics obvious to everyone.\n\nThanks for maintaining Git,\nmit freundlichen Grüßen/Best regards\n/Jesko\n"},{"id":"541071","messageId":"xmqq4ilm7q1n.fsf@gitster.g","threadId":"65450","inReplyTo":"956b1bec-99ec-4d28-8229-804eb14e6d3a@schwarzers.de","subject":"Re: checkout: clarify \"up to date with origin/\" uses local remote-tracking ref","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-04-07T15:23:16Z","receivedAt":"2026-04-07T15:23:19Z","isPatch":false,"body":"Jesko Schwarzer writes:\n\n> Would the project consider one of the following?\n>     1. *Clearer messaging*, e.g. indicating that the comparison is \n> against the last-known origin/ (or similar wording that does not \n> imply a live remote check).\n\nSurely. Patches to start discussions are very much welcome.\n\n>     2. *Optional context* when available (e.g. from reflog or last \n> fetch time), so users know how stale the origin/* ref might be — if that \n> is technically and policy-wise acceptable.\n\nI am imagining that #1 above would add something that conveys\n\"relative to the last known state\", and this will extend/replace the\nphrase you would choose for \"the last known state\" with \"as of N\ndays ago\" or something when necessary pieces of information is\navailable, right? That sounds entirely feasible.\n\n> I understand Git deliberately avoids implicit network access on \n> checkout; the issue is only that the status text does not make the \n> \"local remote-tracking ref\" semantics obvious to everyone.\n"},{"id":"541074","messageId":"5DFBE9D6-0EC8-4702-99C5-827AEF8C6265@gmail.com","threadId":"65450","inReplyTo":"xmqq4ilm7q1n.fsf@gitster.g","subject":"Re: checkout: clarify \"up to date with origin/\" uses local remote-tracking ref","fromName":"Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2026-04-07T16:13:27Z","receivedAt":"2026-04-07T16:13:40Z","isPatch":false,"body":"\n> \n> Le 7 avr. 2026 à 11:28, Junio C Hamano a écrit :\n> \n> Jesko Schwarzer writes:\n> \n>> Would the project consider one of the following?\n>> 1. *Clearer messaging*, e.g. indicating that the comparison is\n>> against the last-known origin/ (or similar wording that does not\n>> imply a live remote check).\n> \n> Surely. Patches to start discussions are very much welcome.\n> \n>> 2. *Optional context* when available (e.g. from reflog or last\n>> fetch time), so users know how stale the origin/* ref might be — if that\n>> is technically and policy-wise acceptable.\n> \n> I am imagining that #1 above would add something that conveys\n> \"relative to the last known state\", and this will extend/replace the\n> phrase you would choose for \"the last known state\" with \"as of N\n> days ago\" or something when necessary pieces of information is\n> available, right? That sounds entirely feasible.\n\nI 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. "},{"id":"541077","messageId":"xmqqpl4a68o0.fsf@gitster.g","threadId":"65450","inReplyTo":"5DFBE9D6-0EC8-4702-99C5-827AEF8C6265@gmail.com","subject":"Re: checkout: clarify \"up to date with origin/\" uses local remote-tracking ref","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-04-07T16:23:59Z","receivedAt":"2026-04-07T16:24:02Z","isPatch":false,"body":"Ben Knoble writes:\n\n> I seem to recall a recent (last ~6 months) thread about “last\n> fetch time” and there being some question of how to record\n> it. Alas I haven’t searched the archives to find it.\n\nIs it a bit older thread?\n\n https://lore.kernel.org/git/xmqqh65b2ci3.fsf@gitster.g/\n\n\n\n"},{"id":"541078","messageId":"xmqqldey68ir.fsf@gitster.g","threadId":"65450","inReplyTo":"xmqqpl4a68o0.fsf@gitster.g","subject":"Re: checkout: clarify \"up to date with origin/\" uses local remote-tracking ref","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-04-07T16:27:08Z","receivedAt":"2026-04-07T16:27:10Z","isPatch":false,"body":"Junio C Hamano writes:\n\n> Ben Knoble writes:\n>\n>> I seem to recall a recent (last ~6 months) thread about “last\n>> fetch time” and there being some question of how to record\n>> it. Alas I haven’t searched the archives to find it.\n>\n> Is it a bit older thread?\n>\n> https://lore.kernel.org/git/xmqqh65b2ci3.fsf@gitster.g/\n\nWrong link. This one is better.\n\n https://lore.kernel.org/git/CALnO6CB2TjwRWr0=c2nWY5DnwLeqXiaA5fCiEeF85zivmLggjA@mail.gmail.com/\n"},{"id":"541166","messageId":"CALnO6CCwKXCxBobO5x2MZZz-AG75haJMaOANjc=KWzjHz1kTrA@mail.gmail.com","threadId":"65450","inReplyTo":"xmqqldey68ir.fsf@gitster.g","subject":"Re: checkout: clarify \"up to date with origin/\" uses local remote-tracking ref","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2026-04-08T18:14:24Z","receivedAt":"2026-04-08T18:14:36Z","isPatch":false,"body":"On Tue, Apr 7, 2026 at 12:27 PM Junio C Hamano wrote:\n>\n> Junio C Hamano writes:\n>\n> > Ben Knoble writes:\n> >\n> >> I seem to recall a recent (last ~6 months) thread about “last\n> >> fetch time” and there being some question of how to record\n> >> it. Alas I haven’t searched the archives to find it.\n> >\n> > Is it a bit older thread?\n> >\n> > https://lore.kernel.org/git/xmqqh65b2ci3.fsf@gitster.g/\n>\n> Wrong link. This one is better.\n>\n> https://lore.kernel.org/git/CALnO6CB2TjwRWr0=c2nWY5DnwLeqXiaA5fCiEeF85zivmLggjA@mail.gmail.com/\n\nYes, I think that thread ended up with some discussion of what\ntimestamps are available and what are not:\n\n https://lore.kernel.org/git/xmqqseottxld.fsf@gitster.g/\n\n-- \nD. Ben Knoble\n"}]}