On Tue, Nov 6, 2018 at 9:57 AM Ævar Arnfjörð Bjarmason <ava...@gmail.com> 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. -- Duy
