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

[Jeff King <peff@peff.net>]

On Thu, Nov 08, 2018 at 09:36:56AM +0900, Junio C Hamano wrote:

> Duy Nguyen <pclouds@gmail.com> writes:
> 
> > There is still one thing to settle. "revert -m1" could produce
> > something like this
> >
> >     This reverts commit <SHA1>, reversing
> >     changes made to <SHA2>.
> 
> I do not think it is relevant, with or without multiple parents, to
> even attempt to read this message.
> 
> The description is not meant to be machine readable/parseable, but
> is meant to be updated to describe the reason why the reversion was
> made for human readers.  Spending any cycle to attempt interpreting
> it by machines will give a wrong signal to encourage people not to
> touch it.  Instead we should actively encourage people to take that
> as the beginning of their description.
> 
> I even suspect that an update to that message to read something like
> these
> 
> 	"This reverts commit <SHA-1> because FILL IN THE REASONS HERE"
> 
> 	"This reverts commit <SHA-1>, reversing changes made to
> 	 <SHA-1>, because FILL IN THE REASONS HERE"

Yeah, that was the point I was trying to make earlier today in this
thread. I really think of this as a human-readable message.

But as far as how this impacts the addition of a trailer: once we have a
machine-readable "Reverts:", people naturally may want to know about
"Reverts" for older commits. Our options are:

  1. say "sorry, there was no machine-readable version back then"

  2. try to parse our "This reverts" message and normalize it into
     "Reverts" for their benefit.

Before introducing the new footer, it's worth thinking about the
end-game here. If we do (1), then people may want to parse themselves.
They are stuck parsing both the old and new (to handle old and new
commits). We could make life a little easier on them if we included
_both_ the English text and the machine-readable version. And then if
they just chose to parse the English, it would work for old and new.

But I guess that is really just a losing battle, if we consider the
English to be changeable. And doing it ourselves in (2) is really just
pushing that losing battle onto ourselves.

So if we are comfortable with saying that this is a new feature to have
the machine-readable trailer version, and there isn't a robust way to
get historical revert information (because there really isn't[1]), then
I think we can just punt on any kind of trailer-normalization magic.

-Peff

[1] Thinking back on reverts I have done, they are often _not_
    straight-up reverts. For example, I may end up dropping half of a
    commit, but leaving some traces of it in place in order to build up
    the correct solution on top (i.e., fixing whatever problem caused me
    to revert in the first place). I list those as "this is morally a
    revert of 1234abcd...", which is definitely not machine readable. ;)