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:
> > On Mon, Jul 18, 2022 at 06:18:11PM +0100, Stephen Finucane wrote:
> > > ...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
