Re: Gerrit, GitButler, and Jujutsu projects collaborating on change-id commit footer

[Patrick Steinhardt <ps@pks.im>]

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