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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeff King <peff@xxxxxxxx> 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.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux