On Fri, Apr 04, 2025 at 11:04:30AM -0500, Nico Williams wrote: > On Fri, Apr 04, 2025 at 11:34:20AM +0200, Patrick Steinhardt wrote: > > > Ah, well, Git does have an index: refs. You could use > > > refs/change-IDs/<change-ID> to index by change ID. > > > > I don't think references are a good mechanism to track change IDs. The > > expectation around refs is that users can change them basically at will, > > but it certainly does not make any sense to let them update change IDs. > > git meta (a separate project) uses refs named refs/commits/$full_hash. > Users can always break their repos in a many many ways. Using refs is > fine. True, they can. But if we use refs as a storage mechanism this means that a remote user can also mess with _your_ repository by introducing a broken `refs/change-IDs/<change-ID>` ref that points to a commit with a different change ID. You can of course work around this by treating such references specially. But that would introduce more complexity into a central subsystem of Git, and the result would probably be another mechanism with leaky abstractions and confusing behaviour. > > Furthermore, as we have already discussed, change IDs are not unique, > > but refs can only point to a single commit ID. So that's another > > mismatch that we cannot address. > > Oh I agree with that! But I think I've made that pretty clear by now :] > > However one could have refs/change-IDs/<change-ID> ultimately point to > an object that lists the commits with that change ID, and then that > would function as an index for non-unique change IDs. That would be possible indeed, but now it's getting even more awkward. So I'm not yet convinced that refs are a good fit for storing cached change IDs. Patrick
