Btw, since we're discussing this, I do think that our current "crlf=input"
syntax for .gitattributes is pretty dubious.
I don't really see why it should be a path-dependent thing on whether you
do crlf conversion on just input or on checkout too. It smells odd. It
makes more sense to me to have a global policy for what the output/input
conversion should be, and then the path rules are just about whether that
conversion gets done or not.
And like it or not, we called that global rule "autocrlf", and then mixed
it up with the decision on whether we should do conversion at all. I do
think that that was a mistake too, and that we could try to fix it, but I
also think that's a fairly independent issue.
So we _could_ introduce a new "core.crlf" config option that talks purely
about what kind of conversion gets done - not about _whether_ it gets
done. So you could do
[core]
crlf=input
and it would imply that crlf conversion is only done on input, but it
would differ from "autocrlf=input" in that it would _not_ imply that any
paths not matched by gitattributes crlf rules would be automatically
converted.
[ And in the above model, "core.autocrlf = input" would just be a
shorthand for saying "core.autocrlf=true" + "core.crlf=input")
So I think we could improve the config file syntax a bit.
But I think that's really a separate issue from the .gitattributes file,
and whether the "crlf" attribute means anythin in the _absense_ of any
config file rules about crlf.
Linus
--
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
