On Tue, Feb 04, 2025 at 09:43:10AM -0800, Junio C Hamano wrote:

And the last step is where the remote-tracking branches are updated,
together with their reflog (if enabled).  Because that step does not
even see the remote-tracking branches whose value do not need to
change (filtered out earlier to help reduce the number of refs fed
to the object transfer machinery), the "drop no-op early" part need
to be designed differently (e.g. mark them as no-op, so that the 
object tranfer machinery can notice them and ignore) and then the
"update refs" step can see these no-op updates.

I do not think writing the "no-op" reflog entries should be done at
a step separate from the step that writes the real ref updates, as I
suspect that such a separate update scheme would have a funny
interactions with "git fetch --atomic".

So, do I think it could be possible?  Sure.  Do I think it would be
too hard as a rocket surgery?  No.  Will I jump up and down excited
and start coding?  I am not interested all that much, but I can help
reviewing patches if somebody else works on it.

There may be some other downsides (other than the cost of storage
and making the reflog noisy) I haven't thought about, which need to
be considered if somebody decides to work on this.

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.

Patrick