kernel/git - git - PowerEL Git System

19921 Commits

6 Branches

36 Tags

131 MiB

Tree: eab58f1e8e

Commit Graph

Author	SHA1	Message	Date
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

Author

SHA1

Message

Date

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

2 Commits (eab58f1e8e5ef86b5075ce6dfcd6d3f1b3b888b3)