On 18/07/18 13:20, Kristian Fiskerstrand wrote: > On 07/18/2018 02:10 PM, Alexis Ballier wrote: >> I often find myself in the >> need to use/invent some abbreviation in order to fit the limit. >> Considering this is an error, this sends the message that short is >> preferred over clear. > Or that the summary should be concise and a longer proper description > can be written in the body of the commit message instead. Potentially > mixed in with multiple commits for different logical changes etc etc. > Perhaps the time has come to re-assess the commit message "standard". I'm thinking something along the lines of the following: - Line one is limited to <cat>/<pkg> and some Key Word that defines the type of change made, similar to bugzilla perhaps eg. "REVBUMP, VERBUMP, EAPIBUMP, BUGFIX, PATCH, FEATUREREQ, OTHER". This would get around the issue of long package-names and/or overlays and other lengthy prefixes. - Line two remains a blank line at present - Line three+ actually describe what the change is, in plain English. - Footer~3: Bug/Pull reference - Footer~2: Signed/Authored/etc standard footer text(s) - Footer: Package manager/repoman as appropriate where: 3+ (line three onwards), ~n: approx. line prior to end (EOF-n)
This should satisfy line length limitations, whilst still preserving some Basic information about commit type, which can then be sub-filtered if necessary. I can't presently see anything that would preclude tool-friendly parsing of such messages... or repoman applying appropriate checks... NB. I may have swapped F~3 and F~2 lines around .. order can be preserved as present.
signature.asc
Description: OpenPGP digital signature
