summaryrefslogtreecommitdiff
path: root/t/t4019-diff-wserror.sh
AgeCommit message (Collapse)AuthorFilesLines
2010-12-12Merge branch 'js/configurable-tab'Libravatar Junio C Hamano1-0/+85
* js/configurable-tab: Make the tab width used for whitespace checks configurable apply --whitespace=fix: fix tab-in-indent
2010-12-01Make the tab width used for whitespace checks configurableLibravatar Johannes Sixt1-0/+85
A new whitespace "rule" is added that sets the tab width to use for whitespace checks and fix-ups and replaces the hard-coded constant 8. Since the setting is part of the rules, it can be set per file using .gitattributes. The new configuration is backwards compatible because older git versions simply ignore unknown whitespace rules. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-29Merge branch 'cm/diff-check-at-eol'Libravatar Junio C Hamano1-0/+9
* cm/diff-check-at-eol: diff --check: correct line numbers of new blank lines at EOF
2010-10-16diff --check: correct line numbers of new blank lines at EOFLibravatar Christoph Mallon1-0/+9
The whitespace check printed the value of the wrong variable, i.e. the beginning of the block of blank lines at the EOF (possibly absent) in the old file. As "git diff --check" is used by users to check their changes before making a commit, we should point at the line number in the file after the change. Signed-off-by: Christoph Mallon <christoph.mallon@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-06t4019 (diff-wserror): add lots of missing &&Libravatar Elijah Newren1-26/+27
Also add test_might_fail in front of the git_config --unset commands that may be trying to unset a value that never got set (due to a previous failing test) or that were already unset. Acked-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-26t4019 "grep" portability fixLibravatar Junio C Hamano1-28/+28
Input to "grep" is supposed to be "text", but we deliberately feed output from "git diff --color" to sift it into two sets of lines (ones with errors, the other without). Some implementations of "grep" only report matches with the exit status, without showing the matched lines in their output (e.g. OpenBSD 4.6, which says "Binary file .. matches"). Fortunately, "grep -a" is often a way to force the command to treat its input as text. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-14diff --whitespace: fix blank lines at endLibravatar Junio C Hamano1-1/+1
The earlier logic tried to colour any and all blank lines that were added beyond the last blank line in the original, but this was very wrong. If you added 96 blank lines, a non-blank line, and then 3 blank lines at the end, only the last 3 lines should trigger the error, not the earlier 96 blank lines. We need to also make sure that the lines are after the last non-blank line in the postimage as well before deciding to paint them. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-04diff --color: color blank-at-eofLibravatar Junio C Hamano1-0/+9
Since the coloring logic processed the patch output one line at a time, we couldn't easily color code the new blank lines at the end of file. Reuse the adds_blank_at_eof() function to find where the runs of such blank lines start, keep track of the line number in the preimage while processing the patch output one line at a time, and paint the new blank lines that appear after that line to implement this. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-04diff --whitespace=warn/error: obey blank-at-eofLibravatar Junio C Hamano1-1/+1
The "diff --check" code used to conflate trailing-space whitespace error class with this, but now we have a proper separate error class, we should check it under blank-at-eof, not trailing-space. The whitespace error is not about _having_ blank lines at end, but about adding _new_ blank lines. To keep the message consistent with what is given by "git apply", call whitespace_error_string() to generate it, instead of using a hardcoded custom message. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-30diff: Help "less" hide ^M from the outputLibravatar Junio C Hamano1-0/+12
When the tracked contents have CRLF line endings, colored diff output shows "^M" at the end of output lines, which is distracting, even though the pager we use by default ("less") knows to hide them. The problem is that "less" hides a carriage-return only at the end of the line, immediately before a line feed. The colored diff output does not take this into account, and emits four element sequence for each line: - force this color; - the line up to but not including the terminating line feed; - reset color - line feed. By including the carriage return at the end of the line in the second item, we are breaking the smart our pager has in order not to show "^M". This can be fixed by changing the sequence to: - force this color; - the line up to but not including the terminating end-of-line; - reset color - end-of-line. where end-of-line is either a single linefeed or a CRLF pair. When the output is not colored, "force this color" and "reset color" sequences are both empty, so we won't have this problem with or without this patch. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-11diff --check: do not unconditionally complain about trailing empty linesLibravatar Junio C Hamano1-1/+19
Recently "git diff --check" learned to detect new trailing blank lines just like "git apply --whitespace" does. However this check should not trigger unconditionally. This patch makes it honor the whitespace settings from core.whitespace and gitattributes. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-05core.whitespace: cr-at-eolLibravatar Junio C Hamano1-0/+40
This new error mode allows a line to have a carriage return at the end of the line when checking and fixing trailing whitespace errors. Some people like to keep CRLF line ending recorded in the repository, and still want to take advantage of the automated trailing whitespace stripping. We still show ^M in the diff output piped to "less" to remind them that they do have the CR at the end, but these carriage return characters at the end are no longer flagged as errors. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-06Use gitattributes to define per-path whitespace ruleLibravatar Junio C Hamano1-0/+47
The `core.whitespace` configuration variable allows you to define what `diff` and `apply` should consider whitespace errors for all paths in the project (See gitlink:git-config[1]). This attribute gives you finer control per path. For example, if you have these in the .gitattributes: frotz whitespace nitfol -whitespace xyzzy whitespace=-trailing all types of whitespace problems known to git are noticed in path 'frotz' (i.e. diff shows them in diff.whitespace color, and apply warns about them), no whitespace problem is noticed in path 'nitfol', and the default types of whitespace problems except "trailing whitespace" are noticed for path 'xyzzy'. A project with mixed Python and C might want to have: *.c whitespace *.py whitespace=-indent-with-non-tab in its toplevel .gitattributes file. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-02core.whitespace: add test for diff whitespace error highlightingLibravatar Junio C Hamano1-0/+76
This tests seletive enabling/disabling of whitespace error highlighting done by colored diff output. Signed-off-by: Junio C Hamano <gitster@pobox.com>