Patrick Steinhardt <ps@xxxxxx> 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? ;-)
