Re: RFC: using supersedes: trailer to indicate patch/series revision flow

[Vegard Nossum <vegard.nossum@oracle.com>]

On 11/7/19 9:43 PM, Konstantin Ryabitsev wrote:
> Hi, all:
> 
> The only mechanism we currently have for patch/series versioning is 
> subject suffixes. I think it would be useful to have a way to more 
> explicitly mark that a series obsoletes a previous version, and I 
> propose this is done with a `supersedes:` trailer at the end of the 
> cover letter or in the first patch of the series:

[...]

I think it's better to put it in the changelog itself (similar to S-O-B,
R-B, A-B, etc. lines) because it allows you to look the information up
straight from a commit once it has been merged.

This is what I suggested under "Step 3", second point here:

https://lore.kernel.org/workflows/b9fb52b8-8168-6bf0-9a72-1e6c44a281a5@oracle.com/

In the scheme I proposed, you would additionally refer to the previous
version by SHA1, which means diffing the patchsets would be as easy as
typing 'git diff' and then pasting the two SHA1s (which would both be
right there in front of you -- no need to follow lore links and applying
patches by hand to compare them).

This is just one data point, but in the team I work in this would be
incredibly useful to have -- we frequently look at upstream/merged
commits and sometimes want to compare them to mailing list submissions
and running git diff/log/range-diff is FAR easier than searching
mailing lists and applying series by hand or trying to figure out by
eyeballing email patches.

> Questions:
> 
[...]
> 2. Should supersedes: link to the previous version of the patch, or the 
>     first ever version of the patch? I am leaning towards the latter,    
> even though in this case the message-id largely becomes identical in    
> usage to Gerrit's Change-Id.

If you add the info to each patch, then it makes sense to link to the
previous version of that patch, since you can always find the first/last
patch from that.

If we also used the merge trick I described to refer to a whole patchset
with a single SHA1 then you can additionally link to the previous
version of that patchset from the merge commit, meaning you effectively
get both (one link in each patch to the previous version of _that_
patch, plus one link in the final merge commit to the previous version
of the full patchset).


Vegard