On Sun, Nov 25, 2007 at 09:36:14PM +0100, Jakub Narebski wrote: > Junio C Hamano wrote: > > > [Actively cooking] > > > > * jc/spht (Sat Nov 24 11:57:41 2007 -0800) 6 commits > > + core.whitespace: documentation updates. > > + builtin-apply: teach whitespace_rules > > + builtin-apply: rename "whitespace" variables and fix styles > > + core.whitespace: add test for diff whitespace error highlighting > > + git-diff: complain about >=8 consecutive spaces in initial indent > > + War on whitespace: first, a bit of retreat. > > > > Now apply also knows about the customizable definition of what > > whitespace breakages are, and I was reasonably happy. But Bruce kicked > > it back from "scheduled to merge" to "still cooking" status, reminding > > that we would want to have this not a tree-wide configuration but > > per-path attribute. And I agree with him. > > Currently apply.whitespace is per repository - would this be changed > as well, There's a difference between the choice of preferred whitespace style and the choice of action to take when encountering "bad" whitespace. The former is (I think) obviously a property of the project (or perhaps of individual paths within the project). The latter may depend on what you're doing with it at any given moment--for example, if I'm applying patches to submit, I generally want to fix whitespace, but if I'm just examining someone else's patches temporarily then I might want to import them quickly without fixing up everything. So, no, I don't think there should be a .gitattribute equivalent to apply.whitespace. --b. > i.e. would it be moved to gitattributes together with custom > diff drivers (or at least custom funcnames), custom merge drivers, > making it per-project (if put under version control) and per-path? > > > By the way, i18n.commitEncoding is per repository, and used to affect > repository; not so with the "encoding" header in commit object. > > -- > Jakub Narebski > Warsaw, Poland > ShadeHawk on #git > > > - > 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 - 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
