El lun, 3 feb 2025 a la(s) 9:10 p.m., Junio C Hamano (gitster@xxxxxxxxx) escribió: > > 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. Thanks for the insightful explanation Junio! Looking forward, do you think that it could be possible to record the timestamp that the remote-tracking branch has been updated with the remote branch? In order to make such information available to the end user. -- .. manuq ..
