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

[Jeff King <peff@peff.net>]

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

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