On Thu, May 21, 2015 at 5: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?
Gentoo's default vim configuration line wraps the commit message at 72 (I think because 72 + an 8-space tab in git log fits in an 80 column window). It also changes the highlighting of the commit title itself after 50 characters. I think both of those are reasonable, although staying in 50 characters for the title is sometimes hard. > >>> - 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. I suppose it could be useful, but I think we've been mostly successful at just expecting people to recognize when what they're writing doesn't look like the code around it. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
