Changing old commit message

Jan-Marek Glogowski glogow at
Wed Nov 14 15:41:22 UTC 2018

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.


More information about the LibreOffice mailing list