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
