[Mesa-dev] [v3 PATCH 01/10] mesa:Define extension ARB_framebuffer_no_attachments

[Connor Abbott]

On Thu, May 21, 2015 at 8:05 PM, Rogovin, Kevin <kevin.rogovin at 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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev