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@xxxxxxxxx> The implementation looks fine to me, but as noted in https://public-inbox.org/git/8736se6qyc.fsf@xxxxxxxxxxxxxxxxxxx/ 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.
