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?
> 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...
> - 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?
