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
