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

Jeff King [off-list ref] writes:

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.

Yes, I do consider that the original suggestion was two-part

 - cherry-pick did have machine readable info, but by historical
   accident, it is shaped differently from "trailers", so we'd
   transition into the new format.

 - revert did not have machine readble info at all, so we are adding
   one, even though it is not that interesting as cherry-pick (for
   the reasons you stated in an earlier message in this thread).

So my "honest answer" is your #1, "sorry, there was no
machine-readable version back then", for reverts.  We do not have
such a problem with cherry-pick luckily ;-)

[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. ;)

Yup, and it is debatable if it even makes sense to add the machine
readable trailer for such a commit.  A human-made claim that it is a
"moral equivalent of reverting X" may not look any different from a
"textual revert of X" to a machine, but the actual patch text would
be quite different---unless the machine reading it understands
"moral equivalence", letting it blindly take on faith whatever
humans say may not be a good idea.