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

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Tue, Nov 06 2018, Nguyễn Thái Ngọc Duy wrote:

> OK here is a less constroversal attempt to add new trailers. Instead
> of changing the default behavior (which could be done incrementally
> later), this patch simply adds a new option --append-trailer to revert
> and cherry-pick.
>
> Both will show either
>
>     Reverts: <commit>[~<num>]
>
> or
>
>     Cherry-picked-from: <commit>[~<num>]
>
> --append-trailer could be added to more commands (e.g. merge) that
> generate commit messages if they have something for machine
> consumption.
>
> After this, perhaps we could have a config key to turn this on by
> default (for revert; for cherry-pick it will turn off "-x" too). Then
> after a couple releases, the we got good reception, we'll make it
> default?
>
> No tests, no proper commit message since I think we're still going to
> discuss a bit more before settling down.
>
> PS. maybe --append-trailer is too generic? We have --signoff which is
> also a trailer. But that one carries more weights than just "machine
> generated tags".
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>

The implementation looks fine to me, but as noted in
https://public-inbox.org/git/8736se6qyc.fsf@evledraar.gmail.com/ I
wonder what the plausible end-game is. That we'll turn this on by
default in a few years, and then you can only worry about
git-interpret-trailers for repos created as of 2020 or something?

Otherwise it seems we'll need to *also* parse out the existing messages
we've added.