Konstantin Ryabitsev <konstantin@xxxxxxxxxxxxxxxxxxx> writes: > 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. My 2 cents, since I used to use Gerrit a lot :) I find persistent per-commit ids really useful, even when patches get moved around. E.g. Gerrit can show and diff previous versions of the patch, which makes it really easy to tell how the patch has evolved over time. That's not to say that we don't need per-topic ids though ;) E.g. Gerrit is pretty bad at handling whole topics - it does naive mapping on a per-commit level, so it has no concept of "these (n - 1) patches should replace these n patches". I, for one, would love to see some kind of "rewrite tracking" in Git. One use case that comes up often is downstream patches, where patches are continuously rebased onto a new upstream; in those cases, it's pretty hard to keep track of how the patch has changed over time
