Hi Johan,
Welcome :)
On 3/30/16 10:36 PM, Johan Hedberg wrote:
Hi,
The MyNewt project does a quite good job at keeping a consistent coding
style through-out the code base, but the current commit history is quite
a mess. Would it be possible to introduce some rules that all git
commits should follow?
In the git based projects I've used in the past the commit message
consists of an initial short summary line (with a short prefix, followed
by a colon + space, and max 70 chars or so width to fit on an 80-wide
terminal with git shortlog), an empty line, and then the main body of
the commit message (also sticking to max 72-74 line length. This makes
browsing the history much easier and the output of git commands that use
the summary line (like shortlog or request-pull) becomes more readable.
+1
Another thing that would be nice to get fixed is for everyone to have
proper and consistent git author information. If you run
"git shortlog -ns" you'll see that some people are duplicated because
of different author names at different times. For the existing history
this can be fixed by having a .mailmap file with lines like the
following (sorry Will for singling you out ;)
Willam San Filippo <[email protected]> <[email protected]>
+1 Let's do this.
As for the coding style, it's indeed very good and consistent across the
code base, but a pet-peeve of mine is still the fact that there's quite
often trailing whitespace on lines (which shows up as bright red in my
editor since my other projects don't tolerate it). My git diff also
shows it as bright red but seems there's no special option to enable
that, perhaps the following in .gitconfig does it:
[diff]
color = auto
Anyway, I'm hoping the project could take this into consideration since
it's clear you do value consistency at least for the coding style.
We do. And... We don't have a CODING_STYLE document :( We've just all
worked together so long. It's on my TOOD, but unfortunately never makes
it to the top. We need it.
I hear you on the end of line thing, I've worked across projects where
this was & wasn't tolerated -- it drove me crazy. If we're going to
adopt this (which I'm for), I think we're going to need some git hook
which automatically checks for this.
Sterling