"J. Bruce Fields" <bfields@xxxxxxxxxxxx> writes: > Yeah, fair enough. Hard to know where to start, though. OK, just to > get an idea, I committed a completely empty tree, made a diff (with > --binary), then applied with --whitespace=fix and compared to the > original. In some cases these seem to be accidental, in some cases > (git-p4) I assume they're intended to use the different style. I personally have this in .git/config [core] whitespace = indent,trail,space and the following three lines in contrib/.gitattributes (untracked) *.py whitespace=!indent,trail,space *.el whitespace=!indent,trail,space fast-import/git-p4 whitespace=!indent,trail,space The latter I added after receiving a fix-up patch from Toby Allsopp a few days ago. I applied git-p4 patch with the strictest rule. As you argued correctly earlier, when we made the whitespace rules per-path using the attributes mechanism, the whitespace policy should be project wide, just like coding style, so I think it is a good idea to have in-tree .gitattributes files that spell out what the policy is more explicitly. At least I think we can all agree that this one entry in the toplevel .gitattributes is a safe and good idea. *.[ch] whitespace I am not sure about the AsciiDoc Documentation. I've always assumed that the docs would format exactly the same before and after running expand and/or unexpand on Documentation/*.txt, and if that is indeed the case we should add *.txt whitespace to Documentation/.gitattributes as well. Then I should _discard_ the one in my .git/config and the untracked contrib/.gitattributes file. - 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
