Re: Changing old commit message

Not much to add to mmeeks mail regarding the commit messages rewrites.

Am 14.11.18 um 13:15 schrieb Michael Meeks:
> On 14/11/2018 11:57, Gülşah Köse wrote:
> > I'd like to ask you about a topic. When Mert closed some bugs about
> > Android that were sponsored by Pardus, I noticed that the commit message
> > was wrong (They want [Pardus] is to be written in commit message) and
> > the patch was merged.

I guess you're talking about the first line of the commit message, which is interpreted by various
tools as a summary.

>       I suspect that we should prolly get a formalized flow to credit commits
> to a given entity when they're submitted by someone else - and hack that
> into our gitdm tooling at some stage - so using some (future)
> machine-readable format would be a good example there; eg. [Pardus].

We already have this as a commit message footer, like Change-Id, Reviewed-on, Tested-by, etc.
Everybody can easily add a "Sponsored-by" "field". No problem to parse this with any tooling I
guess, if we go with a simple "<key>: <value>". We can suggest some default keys, which are used by
our tooling. The Linux kernel mentions some in their Documentation/process/submitting-patches.rst.

Just please don't start putting more stuff in the first commit line, which doesn't describe
technical functionality of the patch.

I would actually move the "tdf#..." to a "Fixes: tdf#12345" and also allow multiple of these
entries. Maybe also a "Regression-from: <commit id>", so it's easier to catch multiple patches when
backporting fixes. As this is managed by humans, it won't be perfect but better then nothing.
Formats like the one used by debian/control even allow multiple lines per key by indention, but we
should be fine without, as the rest of the commit message is free text.

Jan-Marek