Junio C Hamano <gitster@xxxxxxxxx> writes: I need to make some clarification, as the following is misleading. This clarification fortunately does not have to change the patch I sent earlier. > There is another issue with this change. Because "whitespace" without any > string in .gitattributes are defined to cause all the whitespace breakages > known to git to be caught, and tab-in-indent is inherently incompatible > with indent-with-non-tab, this cannot be supported without changing the > definition of "default set of whitespace breakage classes". I said "default" but that is totally incorrect. We catch "trailing-space" and "space-before-tab" by default (i.e. the user does not have any custom "whitespace" attribute), and that will not change. > The intention of allowing .gitattributes to say "*.txt whitespace" is to > let the users and projects say: > > I trust the competence and good judgement made by git developers > regarding whitespace issues. They may devise a new algorithm to catch > common whitespace errors that the current tool may not catch, and when > that happens, I'd like my project to take advantage of the new code > and catch the newly defined classes of errors. > > and that is why we include all whitespace-rule except for the ones that > loosens error conditions to the set of breakages we catch for such a > specification. A corollary to the above clarification on "default" is that people who do not trust us but want to rely on the traditional "Only trailing-space and space-before-tab, nothing else" need to do _nothing_. If they do not have "whitespace" attribute defined for paths, the default is honored. People who want to catch the set of maximal whitespace breakage classes that is internally consistent are the only ones that already have entries like "*.txt whitespace" in their attributes file, and we keep our promises to them. If we take the "all errors known to git" too literally to include incompatible rules in them, the end result would become useless to them, and that is what the earlier update fixes. -- 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