From: Junio C Hamano <gitster@pobox•com>
To: "Manuel Quiñones" <manuel.por.aca@gmail•com>
Cc: git@vger•kernel.org
Subject: Re: Usability issue: "Your branch is up to date"
Date: Mon, 03 Feb 2025 16:10:56 -0800 [thread overview]
Message-ID: <xmqq34guzi0f.fsf@gitster.g> (raw)
In-Reply-To: <xmqqh65b2ci3.fsf@gitster.g> (Junio C. Hamano's message of "Mon, 03 Feb 2025 08:56:20 -0800")
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.
next prev parent reply other threads:[~2025-02-04 0:10 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-03 16:45 Usability issue: "Your branch is up to date" Manuel Quiñones
2025-02-03 16:56 ` Junio C Hamano
2025-02-04 0:10 ` Junio C Hamano [this message]
2025-02-04 0:28 ` Bram van Oosterhout
[not found] ` <CAPx1GveyP4+yn5NMgvO3JpbOwPRT5=tb9YBx7U1Ufvae7gFnHQ@mail.gmail.com>
[not found] ` <CAMoUM6LstYx3PJcx-Sz3Dfs-1BxF1uP373MO8+eknbO7j-S01Q@mail.gmail.com>
2025-02-04 0:51 ` Fwd: " Bram van Oosterhout
2025-02-04 2:08 ` D. Ben Knoble
2025-02-04 12:53 ` Manuel Quiñones
2025-02-05 3:55 ` Bram van Oosterhout
2025-02-04 12:38 ` Manuel Quiñones
2025-02-04 17:43 ` Junio C Hamano
2025-02-05 6:54 ` Patrick Steinhardt
2025-02-05 18:40 ` Junio C Hamano
2025-02-06 9:53 ` Patrick Steinhardt
2025-02-07 8:20 ` Karthik Nayak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq34guzi0f.fsf@gitster.g \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=manuel.por.aca@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox