Changing old commit message
Jan-Marek Glogowski
glogow at fbihome.de
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.
Jan-Marek
More information about the LibreOffice
mailing list