Re: Usability issue: "Your branch is up to date"

[Bram van Oosterhout <adriaanbram0712@gmail.com>]

Ahhhh, this thread explains my confusion when, even though git locally
tells me my branch is "up to date", a fetch demonstrates the branch is
not up to date.

Which begs the question: Why does git say: "Your branch is up to date
..." if at best it can say: "Your
branch MIGHT BE up to date with ..."?

I have learned not to rely on the message and come to expect
(sometimes nasty) surprises when I return to a project after a few
months,

Bram

On Tue, Feb 4, 2025 at 11:11 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> Junio C Hamano <gitster@pobox.com> writes:
>
> > Manuel Quiñones <manuel.por.aca@gmail.com> writes:
> >
> >> that can be fetched from the remote. My proposal: Add the timestamp of
> >> the last fetch to the message. For example:
> >>
> >> ```
> >> $ git switch main
> >> Switched to branch 'main'
> >> Your branch is up to date with 'origin/main'. Last check was 2 hours ago.
> >> ```
> >>
> >> It looks like the timestamp of file `.git/FETCH_HEAD` would be enough
> >> to implement it.
> >
> > Not generally.  Your last fetch may not have been about origin/main
> > (e.g., "git fetch origin next"), or it may even have been about a
> > totally different remote (e.g., "git fetch elsewhere").
> >
> > The timestamp of the last entry of the reflog of origin/main may be
> > a lot better place to look for the information, if available.
>
> Unfortunately, this is not quite enough.
>
> I do not think a "git fetch" that noticed that the remote-tracking
> branch is up-to-date updates the reflog of the remote-tracking
> branch, so if you observed that their 'main' is at certain value 10
> hours ago, and if your more recent fetch done two hours ago found
> that they haven't made any progress, the reflog says "You observed
> that their 'main' is at this commit as of 10 hours ago" and not the
> number you want.
>
> However, as I said, the fetch that touched the FETCH_HEAD file may
> not have been about the ref in question, so while a two-hour old
> FETCH_HEAD can guarantee that update of any ref by fetching
> (including a fetch done as part of "git pull") did not happen in the
> last two hours, it does not really mean what you have in your
> remote-tracking branch is not stale from reality by more than two
> hours.
>
> You could inspect the contents of FETCH_HEAD to see if the source of
> the remote-tracking branch is listed there, and when it appears in
> the file, can use the timestamp of the file.  If you did this:
>
>     $ git fetch origin main
>
> and it left something like
>
>         f93ff170b... branch 'main' of https://www.kernel.org/...
>
> in the file, you can reverse map the URL and the branch using the
> remote.*.URL and the remote.*.fetch configuration variables to
> figure out that it must have been stored at our 'origin/main'.
> At that point, you know that the timestamp of FETCH_HEAD would be
> when we observed that value in the 'origin/main'.
>
> But even then, because the FETCH_HEAD file is not versioned, if you
> did
>
>     $ git fetch elsewhere main
>
> then the file gets overwritten, and you would no longer know when
> was the last time you observed the value of 'origin/main'.
>
> In short, there is not enough information kept anywhere to compute
> the number you want to show reliably.
>