| 1 |
On Wed, 18 Jul 2018 13:47:03 +0100 |
| 2 |
"M. J. Everitt" <m.j.everitt@×××.org> wrote: |
| 3 |
|
| 4 |
> - Line one is limited to <cat>/<pkg> and some Key Word that defines |
| 5 |
> the type of change made, similar to bugzilla perhaps eg. "REVBUMP, |
| 6 |
> VERBUMP, EAPIBUMP, BUGFIX, PATCH, FEATUREREQ, OTHER". This would get |
| 7 |
> around the issue of long package-names and/or overlays and other |
| 8 |
> lengthy prefixes. |
| 9 |
|
| 10 |
Hell no. |
| 11 |
|
| 12 |
I want to see as *much* data as possible in the limited summary, not |
| 13 |
the *LEAST*. |
| 14 |
|
| 15 |
That's why we have this problem in the first place: Developers are |
| 16 |
trying *HARD* to put sufficiently quality information. |
| 17 |
|
| 18 |
This proposal as-is basically champions the line length limitation to |
| 19 |
absurdity. |
| 20 |
|
| 21 |
If you go down this road you may as well "Fix" the problem by forcing |
| 22 |
everyone to make the commit summary the shortened SHA1 of the rest of |
| 23 |
the text in the commit message.... at least that way you're |
| 24 |
*GUARANTEED* to never exceed 50 odd characters. |
| 25 |
|
| 26 |
The commit summary will be useless, but hey, we got that message length |
| 27 |
down alright. Yay! |
Archives