On Tue, Nov 6, 2018 at 11:11 PM Jeff King <p...@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....@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
