Граф коммитов

14 Коммитов

Автор SHA1 Сообщение Дата
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>
2021-01-04 09:44:49 -08:00
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>
2019-06-20 14:03:05 -07:00
Junio C Hamano 3f8c27c369 Merge branch 'ds/hash-independent-tests-fix' into maint
Test portability fix.

* ds/hash-independent-tests-fix:
  .gitattributes: ensure t/oid-info/* has eol=lf
2018-12-15 12:24:32 +09:00
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>
2018-12-14 12:53:06 +09:00
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>
2018-11-12 16:39:17 +09:00
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>
2018-08-29 11:27:31 -07:00
Æ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>
2018-04-27 09:18:55 +09:00
Æ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>
2018-04-27 09:18:55 +09:00
Æ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>
2018-04-27 09:18:55 +09:00
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>
2017-05-10 13:32:50 +09:00
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>
2016-07-07 14:11:15 -07:00
Junio C Hamano 2df3299d86 .gitattributes: detect 8-space indent in shell scripts
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-06 12:22:25 -08:00
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>
2009-06-21 10:42:37 -07:00
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>
2008-02-11 13:23:15 -08:00