On Thu, May 21, 2015 at 8:05 PM, Rogovin, Kevin <kevin.rogo...@intel.com> wrote: > >> This line is too long. (It will not fit in 80 columns in git log since git >> log adds some spaces before each commit message line.) > > What is the accepted maximum length for a line in a commit message? > >>> - extension table >>> - additions to gl_framebuffer >>> >>> v1 -> v2 >>> Spacing and trailing spaces fixes. > >>This looks odd to me. I think you only need 'v2:' here. So, either > > I have seen a number of patches with the notation v1 -> v2 to list changes > between versions. Those patches that I saw using that notation did not have > comments about using the format v1->v2. If people want v2: instead of > v1->v2, I am fine with it, but was just following what I saw in some patch > series. > > Given the number of nits around (that I seem to hit regularly), it might be > beneficial for Mesa to have a short document listing the formatting > requirements, of which I have so far collected: > 1. 80 column limit in source files > 2. Justify comments to 80 columns as well > 3. comparison expressions require spaces around both sides of comparison > operator > 4. successive parenthesis must have spaces between parenthesis > 5. git commit messages have limit of N characters per line (the value of N I > am asking above). > 6. Use "whether condition" when describing a bool instead of "true if > condition is true" > 7. derived values of structs -should- be prefixed with an underscore (this > rule is loaded with exceptions in the code base from its evolution) > 8. "indenting" is 3 spaces, except after switch where it is 0 (but after > case it is 3). > 9. open bracket on same line > 10. no white spaces at end of line > 11. functions for an extension must check if extension is supported and if > not emit an INVALID_OPERATION message instead of relying on function table > dispatch to guarantee they are not called. > 12. (Guessing here) consecutive empty lines are not allowed > 13. If changing a line that violates the nit rules, fix the line too rather > than just adding the change > > I suspect there are more as I listen to the nits, I think it might be > beneficial to collect all the formatting nits and write them down to the > coding standard thing in Mesa so that others can refer to it. Especially > useful for those that work on multiple projects with different coding > standards.
FWIW, the kernel standards for commit messages are at: https://www.kernel.org/doc/Documentation/SubmittingPatches Most of those rules apply to Mesa too. It says the body should be wrapped to 75 chars (although I've been using 72 like Matt said). > > -Kevin > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
