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

From: Junio C Hamano <[email-masked]>
Date: Wed, 05 Feb 2025 10:40:41 -0800

Patrick Steinhardt <[email-masked]> writes:

> One thing to consider is that some remotes tend to have many thousands
> or even hundreds of thousands of references. Updating timestamps for all
> of them could be quite inefficient depending on where exactly that data
> is store. If it was in the form of no-op reflog entries, the "files"
> backend would have to touch as many files as the remote has references.
> Consequently, even if only a single remote ref changed, we'd potentially
> have to update metadata on hundreds of thousands of files.
>
> So I'm not sure whether such a schema would scale well enough in the
> general case for large repos.

I actually view that as quite an orthogonal issue.

Recording the fact that you checked the state of thousands of refs
at the remote and found them unchanged is probably a very small part
of a larger problem that checking the state of thousands of refs is
already expensive.  People have solved it at the protocol level to
limit the ref advertisement to only the relevant refs (as opposed to
the original protocol where the server end unconditionally
advertises the state of all of its refs at the beginning of the
conversation), so when you are only pulling a single branch from
there, you do not even observe the state of other unrelated refs
(like other branches or pull/*/ hierarchy), hence you would not
create these no-op reflog entries.

If the user, on the other hand, is interested in keeping track of
all these thousands of refs, "git fetch" would have to ask and
receive advertisement for all these thousands of refs anyway, and
at that point, recording the no-op update would be a very small
part of the problem, I suspect.  Besides, we have reftable that
would make this kind of problem easier to solve, no? ;-)