On Thu, Apr 03, 2025 at 08:56:01AM -0700, Elijah Newren wrote:
> On Thu, Apr 3, 2025 at 2:13 AM Patrick Steinhardt <ps@xxxxxx> 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?
Yeah, this point wasn't quite clear. It's mostly based around my own
findings that I always end up copying a lot of object IDs around while
working on rebases. And the most annoying part to me is that those OIDs
also change on every rewrite, and as a consequence I always have to look
up the rewritten object IDs.
By using change IDs this issue would become easier as I only need to
remember one set of constant IDs that don't change on ever rewrite.
> > 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...
Yes, some tools already handle this correctly indeed.
> > - Extending revisions to allow specifying commits by change ID.
>
> Would this essentially be similar to <rev>^{/<text>} except searching
> specifically change-id headers rather than commit message?
Yeah, something like that. The exact format for such a new revision
would be up for debate, but I quite like the reverse hex format that JJ
itself uses as it is unambiguous compared to object IDs. Only problem of
course is that it's not unambiguous compared to refnames, so accepting
reverse object IDS as-is without any kind of prefix is probably a no-go.
Patrick
