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: >> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html