On Tue, Nov 6, 2018 at 11:11 PM Jeff King <peff@xxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx/ 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
