On Nov 9, 2010, at 4:07 PM, Junio C Hamano wrote: > 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? My feeling is yes. My suspicion is that paths that begin with a dq are extremely rare, and ones that have custom git attributes set on them are rarer still. I would rather make the change to support an unambiguous format to specify any possible path and simply apologize if anyone is actually hit by this. >> ... 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. Precisely why I was not fond of this suggestion. > 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. Agreed. > 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". Also agreed. I never meant to imply that we didn't care about paths beginning with a dq, I just thought it was unlikely enough that I would never run into someone using such a path ;) In any case, I just took a look at Nguyán's patch and it looks good to me. -Kevin Ballard -- 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