Re: [PATCH/RFC] Support --append-trailer in cherry-pick and revert
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Nov 8, 2018, 03:34 UTC
- Message-ID
- <xmqqh8gs8coe.fsf@gitster-ct.c.googlers.com>
- In-Reply-To
- <20181108012901.GB10148@sigill.intra.peff.net>
Jeff King <peff@peff.net> 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 ;-)
Show 6 quoted lines
> [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.