Hopefully I fixed the author issue; now committing using William San Filippo.
Regarding spaces at the end of lines: did not realize this was an issue at all but I am sure I am a repeat offender :-) Easy enough for me to strip trailing spaces when I save files with my editor. Might cause a few extra diffs at first but whitespace diffs can be ignored… Will > On Mar 31, 2016, at 7:41 AM, Sterling Hughes <[email protected]> wrote: > > 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
