kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

I agree.  We could do a better job with our commit messages.  At the
very least the first line should be a short (< 72 characters, 80
character terminal - the offset of the `git log` command ) descriptive
overview of the changes.  For commit messages with more than one line,
there should be at least one blank line before additional messages.  I'm
not terribly concerned about the formatting after the first line but it
does make for cleaner `git log` output if the lines are less than 72
characters.  I've personally converted to a blank line between each
commit message rather than using an asterisk (*) to denote each message.
 It eliminates the need for padding and IMO is easier to read.

On 1/4/2017 5:34 PM, Chris Pavlina wrote:
> Hey, I don't mean to be too obnoxious of a stickler, but can we work on
> our commit messages just a bit? There are three things I'd really like
> to see improved:
> 
> 1. No vague messages like:
>     - 8e11d9b: very minor change.
> 
>         Better: Realign comments
> 
>     - 995940e: refinement
> 
>         Better: Clean up qrcode_footprint_wizard
> 
> 2. Shorter first line, for easier skimming of logs:
>     - 02fa963: DIALOG_FOOTPRINT_WIZARD_LIST: minor enhancement.
>       qrcode_footprint_wizard.py: use filled polygons instead of square
>       pads on silkscren layer.
> 
>         Better as two commits:
>         - Add number column to DIALOG_FOOTPRINT_WIZARD_LIST
>         - Use filled polygons in *.SilkS in qrcode_footprint_wizard
> 
> 3. Along similar lines, move the "Fixes: lp:nnnnnnn" to the next line:
>     - c45cc1d: Fixes: lp:1653146 (Assertion failed when trying to delete
>       track with router tool active, in debug mode)
> 
>         Better:
>         Fix assertion failure deleting track with router active
> 
>         Fixes: lp:1653146
>         https://bugs.launchpad.net/kicad/+bug/1653146
> 
> I really don't want to single out any individuals in particular; these
> were just the most readily available examples. It does get annoying when
> reading logs though. Can we all try to agree to improve this?
>