Kevin Ballard <kevin@xxxxxx> writes: > Basically what I'm trying to say is, we already break one particular > "rather rare" setup. Let's try again. One particular "rather rare" setup never worked. As it is "rather rare", we do not really care that deeply to make that work. Another particular "rather rare" setup used to work. Even though we do not really care that deeply to keep it working, is it worth breaking it? > ... I would love to come up with a solution that supports both setups, > but I don't know if one exists outside of using a config variable to > control whether git attribute patterns support quoting (a solution I am > not particularly fond of for this case). Controlling this with a config would be a disaster. It would mean that the same version of updated git would interpret the same .gitattributes file differently, and the situation will continue forever. Compared to that, the idea J6t brought up would be far easier to swallow. Older vintage of git will misbehave on "rather rare" paths upon seeing a cquoted pattern (i.e. the pattern will not match the intended paths, and will instead match "rather rare" paths that begin with dq) but that is no worse than what we already have. And newer vintages of git will interpret the attribute file written with that magic exactly the same way everywhere, regardless of the configuration setting. Having said all that, I actually am in favor of using cquote. It would have been what we should have done in the first place. My preference is to admit that we made a mistake of not using cquote when we originally introduced .gitattributes, clearly state that the version of git with this new backward incompatible feature will _break_ rare existing setups if they had paths whose name begin with a dq and applied attributes to them, and use cquote unconditionally, perhaps with a version bump. I just didn't like the tone of saying "Nobody would have used such an insane path anyway so we don't care". I am Ok if our message is "Sorry, this release would break if you used to rely on this; we think it is unlikely and are hoping that most of you won't be affected". -- 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