On Thu, Apr 03, 2025 at 11:23:43PM -0500, Nico Williams wrote: > On Thu, Apr 03, 2025 at 09:08:59PM -0700, Martin von Zweigbergk wrote: > > > and even then still not workable because Git might > > > have to search _many_ branches to find commits matching the given change > > > ID. (Fossil could have an index on change ID and trivially make that > > > search possible, but for Git adding an index is more complicated.) > > > > Yes, I understand that it would be significant work to add support in > > Git. I hope that Git can gain the feature eventually, but we have no > > expectation that it will be implemented soon, especially not the UX > > part (the preservation-on-rewrite part should be simpler, I think). > > 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. 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. I think caching the information in an auxiliary data structure would thus be a lot more reasonable. This could for example be part of commit graphs, but could also be a separate index specific to change IDs themselves. Patirck
