kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Junio C Hamano	ffd27e6cb2	CoC: explicitly take any whitespace breakage We'll keep this document mostly in sync with the upstream; let's help "git am" and "git show" by telling them that they may introduce what we may consider whitespace errors. Signed-off-by: Junio C Hamano <gitster@pobox.com>	4 years ago
Johannes Schindelin	b71c6c3b64	Fix build with core.autocrlf=true 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> Signed-off-by: Pratyush Yadav <me@yadavpratyush.com>	5 years ago
Johannes Schindelin	a5bdf9fdf1	Mark .bat files as requiring CR/LF endings Just like the natural line ending for Unix shell scripts consist of a single Line Feed, the natural line ending for (DOS) Batch scripts consists of a Carriage Return followed by a Line Feed. It seems that both Unix shell script interpreters and the interpreter for Batch scripts (`cmd.exe`) are keen on seeing the "right" line endings. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Derrick Stolee	fc767afe77	.gitattributes: ensure t/oid-info/* has eol=lf The new test_oid machinery in the test library requires reading some information from t/oid-info/hash-info and t/oid-info/oid. The logic to read from these files in shell uses built-in "read" command, which leaves CR at the end of these text files when they are checked out with CRLF line endings, at least when run with bash shipped with Git for Windows. This results in an unexpected value in the variable these lines are read into, leading the tests to fail. Mark them to be checked out always with the LF line endings. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Nguyễn Thái Ngọc Duy	54709d5204	build: fix broken command-list.h generation with core.autocrlf The script generate-cmdlist.sh needs input text files in UNIX line ending to work correctly. It's been fine even with core.autocrlf set because Documentation/git-.txt is forced LF conversion. But this leaves out gitk.txt and also Documentation/config.txt that recently becomes new input for this script. Update the attribute file to force LF on all *.txt files to be on the safe side. For more details, please see `00ddc9d13c` (Fix build with core.autocrlf=true - 2017-05-09) Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Thomas Gummerer	b9b07efdb2	.gitattributes: add conflict-marker-size for relevant files Some files in git.git contain lines that look like conflict markers, either in examples or tests, or in the case of Documentation/gitk.txt because of the asciidoc heading. Having conflict markers the same length as the actual content can be confusing for humans, and is impossible to handle for tools like 'git rerere'. Work around that by setting the 'conflict-marker-size' attribute for those files to 32, which makes the conflict markers unambiguous. Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	6 years ago
Ævar Arnfjörð Bjarmason	7818b619e2	.gitattributes: add a diff driver for Python Declare that the .py files in our tree are Python for the purposes of diffing, and as in `00ddc9d13c` ("Fix build with core.autocrlf=true", 2017-05-09) set eol=lf on them, which makes sense like with the .perl files. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	7 years ago
Ævar Arnfjörð Bjarmason	20460635a8	.gitattributes: use the "perl" differ for Perl As noted in gitattributes(5) this gives better patch context for these types of files. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	7 years ago
Ævar Arnfjörð Bjarmason	00acdbc6fd	.gitattributes: add .pl extension for Perl Change the list of Perl extensions added in `00ddc9d13c` ("Fix build with core.autocrlf=true", 2017-05-09) to also include .pl, we have some of those in the tree, e.g. in t/. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	7 years ago
Johannes Schindelin	00ddc9d13c	Fix build with core.autocrlf=true 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>	8 years ago
René Scharfe	e82675a040	.gitattributes: set file type for C files 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>	9 years ago
Pat Thoyts	6f01e20e25	git-gui: set whitespace warnings appropriate to this project Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>	13 years ago
Junio C Hamano	2df3299d86	.gitattributes: detect 8-space indent in shell scripts Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Nanako Shiraishi	e2f6331a14	.gitattributes: CR at the end of the line is an error 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>	16 years ago
Shawn O. Pearce	1ffca60f0b	git-gui: Use gitattribute "encoding" for file content display Most folks using git-gui on internationalized files have complained that it doesn't recognize UTF-8 correctly. In the past we have just ignored the problem and showed the file contents as binary/US-ASCII, which is wrong no matter how you look at it. This really should be a per-file attribute, managed by .gitattributes, so we now pull the "encoding" attribute data for the given path from the .gitattributes (if available) and use that, falling back to UTF-8 if the attributes are unavailable, git-check-attr is broken, or an encoding for this path not specified. We apply the encoding anytime we show file content, which currently is limited to only the diff viewer and the blame viewer. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>	17 years ago
Junio C Hamano	14f9e128d3	Define the project whitespace policy 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>	17 years ago

14 Commits (2f4ba2a867f0390f139b622dbafcab766cb88e80)