On Tue, Nov 06 2018, Duy Nguyen wrote: > On Tue, Nov 6, 2018 at 9:57 AM Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: >> 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.
