Jim Meyering [off-list ref] writes:
GNU diff's --suppress-blank-empty option makes it so that diff does not
add a space or tab before each empty output line of context. With this
option, empty context lines are empty also in "git diff" output.
AFAIK, ERN 103/120 inspired by your comment merely says an empty context
is either an empty line or a line with a single space on it and does not
deprecate the latter, more traditional, form (I do not know the current
status of the update to the POSIX --- what's the recommended way to find
it out by outsiders?)
We've hacked the patch application side to accomodate this special case to
grok output from recent GNU diff already. Can't we just stop at that,
without having to do the same for generation side? What's the downside of
not doing so?
Junio C Hamano <gitster <at> pobox.com> writes:
Jim Meyering <jim <at> meyering.net> writes:
quoted
GNU diff's --suppress-blank-empty option makes it so that diff does not
add a space or tab before each empty output line of context. With this
option, empty context lines are empty also in "git diff" output.
AFAIK, ERN 103/120 inspired by your comment merely says an empty context
is either an empty line or a line with a single space on it and does not
deprecate the latter, more traditional, form (I do not know the current
This is not a POSIX compliance issue.
Either format may be emitted.
status of the update to the POSIX --- what's the recommended way to find
it out by outsiders?)
Here's one copy of what's being added to the latest version of POSIX:
http://www.opengroup.org/austin/aardvark/latest/xcubug2.txt
Anyone can register (see Q2: http://www.opengroup.org/austin/faq.html)
and then get the lastest draft, but it should be final (and hence public)
pretty soon.
We've hacked the patch application side to accomodate this special case to
grok output from recent GNU diff already. Can't we just stop at that,
without having to do the same for generation side? What's the downside of
not doing so?
No pressure to add it to git. I deliberately did not propose that,
based on the reception an earlier proposal received in this forum.
I tried to make that clear in the header comments.
However, here's why I use this patch:
- there are many contexts where I try to avoid trailing blanks, and
eliminating spurious ones makes it easier to spot possibly-problematic ones.
- I version-control some diff output, and having diff-generating programs
handle the elimination of unnecessary trailing blanks is slightly safer
than doing it from each context.
- some tools systematically remove or highlight trailing blanks. If I can
make my diff output less susceptible with such an option, I'll use it.
Bottom line, it doesn't really matter.
I posted the patch in case someone else would find it useful.