Re: RFC: Superseded-by: follow-up trailer

[Konstantin Ryabitsev <konstantin@linuxfoundation.org>]

On Wed, Apr 14, 2021 at 12:57:33PM -0300, Jason Gunthorpe wrote:
> > The best workflow I can recommend here is:
> > 
> > 1. create a new branch from the latest upstream, e.g. myfoo_v1
> > 2. "b4 am/git am" your own v1 (this has an added bonus of rebasing it)
> > 3. create a new branch from myfoo_v1 as myfoo_v2
> > 4. make any changes to myfoo_v2
> 
> This isn't workable - it assumes the user will only change the patches
> after all the tags have been sent because it resets the whole branch
> to the as-sent condition.
> 
> Usually I would make changes to the series as the discussion evolves
> and resync the tags only before resending the next version.

Okay, this is fair. Is this any better:

1. "b4 am" learns a --newrev flag that populates "Obsoletes:" trailers 
   for your own patches it grabs from the list
2. when you're ready to start working on the new version, you run "b4 am
   --newrev" that prepares a mbox file with Obsoletes: trailers, and you
   "git am" it to a new branch (similar to what I described above)
3. b4 additionally learns a command to grab new trailers from the list by
   matching the Obsoletes: message-ids and auto-amending commits with any new
   trailers

This would allow you to start working on a new revision whenever you're ready
for it and give b4 a precise match it can rely on when tracking new trailers.

-K