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 see my test commits here: https://lore.kernel.org/linux-patches/20220707-my-new-branch-v1-0-8d355bae1bb5@xxxxxxxxxxxxxxxxxxx/ You will notice that each cover letter has the following in the basement: --- base-commit: 88084a3df1672e131ddc1b4e39eeacfd39864acf change-id: 20220707-my-new-branch-[uniquerandomstr] There are 3 revisions of the series and you can locate all of them by searching for that trailer: https://lore.kernel.org/linux-patches/?q=%22change-id%3A+20220707-my-new-branch-1325e0e7fd1c%22 Note, that "b4 submit" is in the early experimental stage and will likely undergo significant changes in the next few weeks, so I wouldn't treat it as any more than curiosity at this point. -K
