From: Duy Nguyen <pclouds@gmail.com>
Date: Wed, 07 Nov 2018 15:30:38 GMT
Subject: Re: [PATCH/RFC] Support --append-trailer in cherry-pick and revert
Message-ID: <CACsJy8DTdW-P9zG3DBPArjhZU1VwwBmd7qNibyHxYkyjRrdWmw@mail.gmail.com>
In-Reply-To: <20181106221118.GA9975@sigill.intra.peff.net>

On Tue, Nov 6, 2018 at 11:11 PM Jeff King <peff@peff.net> wrote:
>
> On Tue, Nov 06, 2018 at 06:48:22PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
> > 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