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

From: Jeff King <peff@peff.net>
Date: Nov 7, 2018, 21:02 UTC
Message-ID: <20181107210256.GC30078@sigill.intra.peff.net>
In-Reply-To: <CACsJy8DTdW-P9zG3DBPArjhZU1VwwBmd7qNibyHxYkyjRrdWmw@mail.gmail.com>

On Wed, Nov 07, 2018 at 04:30:38PM +0100, Duy Nguyen wrote:

Show 30 quoted lines

> > 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.

IMHO the revert case is way less interesting for automated parsing. In a workflow like Git's, cherry-picks aren't very common, but there _are_ workflows where there's a lot of cherry-picking between dev/release branches, and automated analysis is useful there. Whereas for revert, it's almost always a human-scale thing. A commit was bad, so you revert it. The annotation is useful if you're digging, but it's not generally going to be a fundamental part of a workflow. And it's not really any different than fixing a bug later.

And I think that's reflected in the way we just casually stick the reverted oid in the human-readable part of the commit message (and the lack of any tools to parse it).

So IMHO it would be OK to treat this less carefully than the cherry-pick case.

-Peff