Commit graph

8 commits

Author SHA1 Message Date
Junio C Hamano d68fe26f3e diff --whitespace: fix blank lines at end
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-14 22:18:36 -07:00
Junio C Hamano 690ed84363 diff --color: color blank-at-eof
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-04 11:50:27 -07:00
Junio C Hamano 5b5061efd8 diff --whitespace=warn/error: obey blank-at-eof
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>
2009-09-04 11:50:26 -07:00
Junio C Hamano 3928097020 diff: Help "less" hide ^M from the output
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-30 20:34:45 -07:00
Junio C Hamano 04c6e9e9ca diff --check: do not unconditionally complain about trailing empty lines
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-08-11 22:15:28 -07:00
Junio C Hamano b2979ff599 core.whitespace: cr-at-eol
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>
2008-02-05 00:38:41 -08:00
Junio C Hamano cf1b7869f0 Use gitattributes to define per-path whitespace rule
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-12-06 00:45:30 -08:00
Junio C Hamano 49e703afda core.whitespace: add test for diff whitespace error highlighting
This tests seletive enabling/disabling of whitespace error
highlighting done by colored diff output.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-02 17:58:09 -07:00