Junio C Hamano <gitster@xxxxxxxxx> writes:
> Manuel Quiñones <manuel.por.aca@xxxxxxxxx> 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.
