On Mon, 2022-07-18 at 21:04 +0200, Michal Suchánek wrote:

On Mon, Jul 18, 2022 at 01:35:11PM -0400, Konstantin Ryabitsev wrote:

quoted

On Mon, Jul 18, 2022 at 06:18:11PM +0100, Stephen Finucane wrote:

quoted

...to track evolution of a patch through time.

tl;dr: How hard would it be to retrofit an 'ChangeID' concept à la the 'Change-
ID' trailer used by Gerrit into git core?

I just started working on this for b4, with the notable difference that the
change-id trailer is used in the cover letter instead of in individual
commits, which moves the concept of "change" from a single commit to a series
of commits. IMO, it's much more useful in that scope, because as series are
reviewed and iterated, individual patches can get squashed, split up or
otherwise transformed.

You can turn that around and say that IDs of individual commits are more
powerful because they are preserved as series are reviewed, split,
merged, and commits cherry-picked.

There's also the fact that many communities insist on small, atomic commits:
they're much easier to review. It stands to reason that reviewing a series on a
patch-by-patch basis is also much easier, as is reviewing a series _revision_ on
a patch-by-patch basis. To be able to do this though, you need to be able to map
patch revisions to their predecessors/successors and well as the series
revisions. I don't see how you realistically rely on a series-only identifier.

There's no reason 'git-format-patch' couldn't allow you to set an
AuthorID/ChangeID/<whatever we want to call this field> value for a cover
letter, though it obviously would need to be done manually since cover letters
aren't git objects.

  git send-email \
    --reroll-count 2 \
    --series-id 300628e5-8b27-45fe-be71-95417f7ccd6f
    main

Stephen

Thanks

Michal