Kevin Ballard [off-list ref] 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".
On Nov 9, 2010, at 4:07 PM, Junio C Hamano wrote:
Kevin Ballard [off-list ref] writes:
quoted
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.
quoted
... 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