Re: [PATCH 0/9] War on blank-at-eof

On Fri, 4 Sep 2009, Junio C Hamano wrote:

Patch 5 corrects the definition of blank-at-eof.  If a patch adds an
non-empty line that consists solely of whitespaces at the end of file, we
should diagnose and strip it just line a new empty line.  After all, both
are blank lines.

Thank you. Thank you, thank you. Thank you!  And did I mention thank you?

Tested this out after cherry-picking:
3b5ef0e xutils: Fix xdl_recmatch() on incomplete lines
78ed710 xutils: Fix hashing an incomplete line with whitespaces at the end

It worked as nicely!  I'm throwing away the --allow-whitelines-at-eof 
patch! :D  Converting a _real_ dirty whitespace branch into an 'almost' 
whitespace policy compliant branch with validation of the diffs was 
able to be done like so:
	git diff -b DIRTY CLEAN
	git diff DIRTY^ CLEAN > diff1
	git diff CLEAN^ DIRTY > diff2
	git diff -b diff1 diff2

I mention 'almost' above because unfortunately this type of conversion 
leaves extra line-spaces at the end of some files that you might not want 
to have in a whitespace policy.

While thinking about what appeared in:

http://article.gmane.org/gmane.comp.version-control.git/124138
Junio C Hamano <gitster <at> pobox.com> writes:

Bruno Haible <bruno <at> clisp.org> writes:

quoted

In some GNU projects, there are file types for which trailing spaces in a line
...
Currently the user has to turn off the 'trailing-space' whitespace attribute
in order for 'git diff --check' to not complain about such files. This has
the drawback that trailing spaces are not detected.

Very good problem description.  Thanks.

I thought it might be interesting to throw this out there...  What do you 
think of an additional attribute value like
	core.whitespace blank-at-eof-min-<some 0 to N #>
	core.whitespace blank-at-eof-max-<some 0 to N #>
that could be read in when core.whitespace blank-at-eof is set.

If neither are present then use current. (No new eof blanks).
If min but not max is set then allow new blanks and ensure at least min.
If max but not min is set then only allow max blanks at eof.
If both then treat it as a boundary.

This could ensure a whitespace policy without the repository maintainer 
having to correct this type of minutia and without having to nit-pick 
contributors into submission.

Then perhaps diff could also recognize an in range blank-at-eof so a diff 
using one of the ignore whitespace options would ignore eof whitelines 
that are in range?

The series applies to v1.6.0.6-87-g82d97da; merging the result to 'master'
needs some conflict resolution.

-- 
Thell