Re: What's cooking in git.git (topics)

On Sun, Nov 25, 2007 at 09:36:14PM +0100, Jakub Narebski wrote:

Junio C Hamano wrote:

quoted

[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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html