summaryrefslogtreecommitdiff
path: root/.clang-format
AgeCommit message (Collapse)AuthorFilesLines
2019-02-22trace2: add for_each macros to clang-formatLibravatar Jeff Hostetler1-1/+1
Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-09editorconfig: indicate settings should be kept in syncLibravatar brian m. carlson1-0/+2
Now that we have two places where we set code formatting settings, .editorconfig and .clang-format, it's possible that they could fall out of sync. This is relatively unlikely, since we're not likely to change the tab width or our preference for tabs, but just in case, add comments to both files reminding future developers to keep them in sync. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Reviewed-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-01-24clang-format: adjust penalty for return type line breakLibravatar Patryk Obara1-1/+1
The penalty of 5 makes clang-format very eager to put even short type declarations (e.g. "extern int") into a separate line, even when breaking parameters list is sufficient. Signed-off-by: Patryk Obara <patryk.obara@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-02clang-format: add a comment about the meaning/status of theLibravatar Stephan Beyer1-1/+5
Having a .clang-format file in a project can be understood in a way that code has to be in the style defined by the .clang-format file, i.e., you just have to run clang-format over all code and you are set. This unfortunately is not yet the case in the Git project, as the format file is still work in progress. Explain it with a comment in the beginning of the file. Additionally, the working clang-format version is mentioned because the config directives change from time to time (in a compatibility-breaking way). Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-01clang-format: adjust line break penaltiesLibravatar Johannes Schindelin1-6/+6
We really, really, really want to limit the columns to 80 per line: One of the few consistent style comments on the Git mailing list is that the lines should not have more than 80 columns/line (even if 79 columns/line would make more sense, given that the code is frequently viewed as diff, and diffs adding an extra character). The penalty of 5 for excess characters is way too low to guarantee that, though, as pointed out by Brandon Williams. From the existing clang-format examples and documentation, it appears that 100 is a penalty deemed appropriate for Stuff You Really Don't Want, so let's assign that as the penalty for "excess characters", i.e. overly long lines. While at it, adjust the penalties further: we are actually not that keen on preventing new line breaks within comments or string literals, so the penalty of 100 seems awfully high. Likewise, we are not all that adamant about keeping line breaks away from assignment operators (a lot of Git's code breaks immediately after the `=` character just to keep that 80 columns/line limit). We do frown a little bit more about functions' return types being on their own line than the penalty 0 would suggest, so this was adjusted, too. Finally, we do not particularly fancy breaking before the first parameter in a call, but if it keeps the line shorter than 80 columns/line, that's what we do, so lower the penalty for breaking before a call's first parameter, but not quite as much as introducing new line breaks to comments. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-14clang-format: outline the git project's coding styleLibravatar Brandon Williams1-0/+165
Add a '.clang-format' file which outlines the git project's coding style. This can be used with clang-format to auto-format .c and .h files to conform with git's style. Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>