summaryrefslogtreecommitdiff
path: root/.gitattributes
AgeCommit message (Collapse)AuthorFilesLines
2017-05-10Fix build with core.autocrlf=trueLibravatar Johannes Schindelin1-1/+7
On Windows, the default line endings are denoted by a Carriage Return byte followed by a Line Feed byte, while Linux and MacOSX use a single Line Feed byte to denote a line ending. To help with this situation, Git introduced several mechanisms over the last decade, most prominently the `core.autocrlf` setting. Sometimes, however, a single setting is incorrect, e.g. when certain files in the source code are to be consumed by software that can handle only LF line endings, while other files can use whatever is appropriate for the current platform. To allow for that, Git added the `eol` option to its .gitattributes handling, expecting every user of Git to mark their source code appropriately. Bash assumes that line-endings of scripts are denoted by a single Line Feed byte. Therefore, shell scripts in Git's source code are one example where that `eol=lf` option is *required*. When generating common-cmds.h, the Unix tools we use generally operate on the assumption that input and output deliminate their lines using LF-only line endings. Consequently, they would happily copy the CR byte verbatim into the strings in common-cmds.h, which in turn makes the C preprocessor barf (that interprets them as MacOS-style line endings). Therefore, we have to mark the input files as LF-only: command-list.txt and Documentation/git-*.txt. Quite a bit belatedly, this patch brings Git's own source code in line with those expectations by setting those attributes to allow for a correct build even when core.autocrlf=true. This patch can be validated even on Linux, by using this cadence: git config core.autocrlf true rm .git/index && git stash make -j15 DEVELOPER=1 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>
2016-07-07.gitattributes: set file type for C filesLibravatar René Scharfe1-1/+1
Set the diff attribute for C source file to "cpp" in order to improve git's ability to determine hunk headers. In particular it helps avoid showing unindented labels in hunk headers. That in turn is useful for git diff -W and git grep -W, which show whole functions now instead of stopping at a label. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-06.gitattributes: detect 8-space indent in shell scriptsLibravatar Junio C Hamano1-0/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-21.gitattributes: CR at the end of the line is an errorLibravatar Nanako Shiraishi1-1/+1
When a CR is accidentally added at the end of a C source file in the git project tree, "git diff --check" doesn't detect it as an error. $ echo abQ | tr Q '\015' >>fast-import.c $ git diff --check I think this is because the "whitespace" attribute is set to *.[ch] files without specifying what kind of errors are caught. It makes git "notice all types of errors" (as described in the documentation), but I think it is incorrectly setting cr-at-eol, too, and hides this error. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-11Define the project whitespace policyLibravatar Junio C Hamano1-0/+2
This establishes what the "bad" whitespaces are for this project. The rules are: - Unless otherwise specified, indent with SP that could be replaced with HT are not "bad". But SP before HT in the indent is "bad", and trailing whitespaces are "bad". - For C source files, initial indent by SP that can be replaced with HT is also "bad". - Test scripts in t/ and test vectors in its subdirectories can contain anything, so we make it unrestricted for now. Anything "bad" will be shown in WHITESPACE error indicator in diff output, and "apply --whitespace=warn" will warn about it. Signed-off-by: Junio C Hamano <gitster@pobox.com>