Re: [PATCH/RFC v2] sequencer.c: record revert/cherry-pick commit with trailer lines

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Nov 4, 2018, 21:30 UTC
Message-ID: <20181104213007.GL731755@genre.crustytoothpaste.net>
In-Reply-To: <20181104181026.8451-1-pclouds@gmail.com>

On Sun, Nov 04, 2018 at 07:10:26PM +0100, Nguyễn Thái Ngọc Duy wrote:

Show 22 quoted lines

> When a commit is reverted (or cherry-picked with -x) we add an English
> sentence recording that commit id in the new commit message. Make
> these real trailer lines instead so that they are more friendly to
> parsers (especially "git interpret-trailers").
> 
> A reverted commit will have a new trailer
> 
>     Revert: <commit-id>
> 
> Similarly a cherry-picked commit with -x will have
> 
>     Cherry-picked-from: <commit-id>
> 
> When reverting or cherry picking a merge, the reverted/cherry-picked
> branch will be shown using extended SHA-1 syntax, e.g.
> 
>     Revert: <commit-id>~2
> 
> Since we're not producing the old lines "This reverts commit ..." and
> "(cherry picked from commit .." anymore, scripts that look for these
> lines will need to be updated to handle both. Fresh new history could
> just rely on git-interpret-trailers instead.

Overall, I like the idea of this series. This is a much cleaner way to handle things and much better for machine-readability. I foresee git cherry potentially learning how to parse this, for example, for cases where the patch-id doesn't match due to context changes.

However, I do have concerns about breaking compatibility with existing scripts. I wonder if we could add a long alias for git cherry-pick -x, say "--notate" and have "--notate=text" mean "-x" and "--notate=trailer" mean this new format. Similarly, git revert could learn such an option as well.

One final thought: since our trailers seem to act as if we wrote "this commit" (has been), I wonder if we should say "Reverts" instead of "Revert" for consistency.

-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204