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