Re: [PATCH/RFC] Support --append-trailer in cherry-pick and revert

On Tue, Nov 6, 2018 at 11:11 PM Jeff King [off-list ref] wrote:

On Tue, Nov 06, 2018 at 06:48:22PM +0100, Ævar Arnfjörð Bjarmason wrote:

quoted

The implementation looks fine to me, but as noted in
https://public-inbox.org/git/8736se6qyc.fsf@evledraar.gmail.com/ I
wonder what the plausible end-game is. That we'll turn this on by
default in a few years, and then you can only worry about
git-interpret-trailers for repos created as of 2020 or something?

Otherwise it seems we'll need to *also* parse out the existing messages
we've added.

Could we help the reading scripts by normalizing old and new output via
interpret-trailers, %(trailers), etc?

I think "(cherry picked from ...)" is already considered a trailer by
the trailer code. If the caller instructs us to, we could probably
rewrite it to:

  Cherry-picked-from: ...

in the output. Then the end-game is that scripts should just use
interpret-trailers, etc, and old and new commits will Just Work.

There is still one thing to settle. "revert -m1" could produce
something like this

    This reverts commit <SHA1>, reversing
    changes made to <SHA2>.

My proposal produces this

    Reverts: <SHA1>^2

And I can't really convert the former to latter without accessing
object database (probably not a good idea?) to check if SHA2 is the
second parent of SHA1. So either

 - I access object database anyway
 - Generate just "Reverts: <SHA1>" (i.e. losing info) with interpret-trailers
 - Change Reverts: tag to a different output format, or maybe use two
tags instead.
-- 
Duy