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

On Tue, Nov 06 2018, Duy Nguyen wrote:

On Tue, Nov 6, 2018 at 9:57 AM Ævar Arnfjörð Bjarmason [off-list ref] wrote:

quoted

Leaving aside the question of whether the pain of switching is worth it,
I think it's a worthwihle to consider if we could stop hardcoding one
specific human language in commit messages, and instead leave something
machine-readable behind.

We do that with reverts, and also with merge commits, which could be
given a similar treatment where we change e.g. "Merge branches
'jc/convert', 'jc/bigfile' and 'jc/replacing' into jc/streaming" (to use
git.git's 02071b27f1 as an example) to:

    Merge-branch-1: jc/convert
    Merge-branch-2: jc/bigfile
    Merge-branch-3: jc/replacing
    Merge-branch-into: jc/streaming

Then, when rendering the commit in the UI we could parse that out, and
put a "Merge branches[...]" message at the top, except this time in the
user's own language.

My first reaction of this was "but branch name is a local thing and
not significant anyway!". But then if people use one branch as a
bundle of other branches like 'pu', then the ability to recreate
branches (with the right name of course) from those merges may be
useful. So... yeah, maybe.

Yeah, in theory, in practice no. But all I'm observing is that we're
*already* encoding this information, so to me at least the logical end
game to changes like what you're proposing is something like the above,
otherwise why bother?

But having thought about it a bit more I wonder if
git-interpret-trailers (or some command like it) shouldn't just as a
special-case learn to do more parsing of commit messages we've
historically generated.

E.g. know how to parse out a merge message we've produced and spew out
something like the above Merge-* output. Same for existing "Revert"
output, if anyone cares about parsing this they'll need to do that
anyway.