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

> On Thu, Apr 3, 2025 at 2:13 AM Patrick Steinhardt <ps@pks.im> wrote:
> >
> [...]
> > Agreed, change IDs solve a couple of issues that many users face:
> >
> >   - You can reliably track how a patch evolves over time. This helps
> >     various different tools to track identity of commits, like for
> >     example forges, but also tools like git-range-diff(1).
> >
> >   - It becomes trivial to see whether a commit has been cherry-picked
> >     into another branch. We do have git-cherry(1) to do that right now,
> >     but that command is based on heuristics and fails as soon as the
> >     patch itself needed to be adapted.
> >
> >   - Working with history rewrites becomes easier in the general case as
> >     you don't have to adapt to constantly changing commit IDs.
> 
> Could you elaborate?  I agree with the other points you raise, but I'm
> unsure how this helps with a history rewrite.  Do you mean the
> rewriting of history, or someone trying to consume the history
> rewrite?  If the former, I don't see it, and if the latter, didn't you
> already cover that in the two bullets above?  Or is there something
> else you are also getting at?

> > So what would it take to get change IDs into Git? I think the most
> > important items would be:
> >
> >   - Generating and writing change IDs in commands that support them.
> >     This includes e.g. git-commit(1), git-commit-tree(1), git-merge(1),
> >     git-merge-tree(1). This should of course be completely optional and
> >     probably be disabled by default.
> >
> >   - Making tools that rewrite commits aware of change IDs so that they
> >     know to retain change IDs. This involves e.g. git-cherry-pick(1),
> >     git-rebase(1), git-replay(1).
> 
> And also git-commit(1) [when passing --amend], and git-fast-export(1)
> and git-fast-import(1) -- though possibly with options for the last
> two to expunge them instead of preserving them, but probably
> defaulting to preserving them.
> 
> However, I think some of these might already handle this.  Commands
> which call read_commit_extra_headers() and pass those along to
> commit_tree_extended() may already preserve these.  It appears commit
> --amend and replay both do this.  sequencer has some code that looks
> relevant, but it appears to only be reading the headers from HEAD (at
> the time the nth commit is being replayed), which seems like it'd be
> looking at the wrong commit.  That might actually be a bug...