Nguyen Thai Ngoc Duy [off-list ref] writes:
Migration plan:
I think a release note mentioning this is enough. No migration needed.
But to be safe, we can make post-1.7.5 warn users about patterns with
leading double quote. By 1.8.0, the new behavior will be used.
That's obviously not a migration plan, and it is worse than not having the
warning at all. People with paths that begin with dq (which I suspect
would be an empty set) will get wraning every time they do anything with
git, and until 1.8.0 there is no way to turn that warnings off without
breaking their pattern (like removing the entry from the attributes file),
and when 1.8.0 comes their patterns will break.
How about introducing a new feature in .gitattributes file so that the
parser can tell if the file is (1) written pre-1.7.5 that depends on the
old behaviour, (2) written post-1.7.5 by a person who is aware of the dq
convention, but still relying on the old behaviour, (3) written post-1.7.5
to take advantage of the new behaviour? E.g., you can explicitly mark
your .gitattributes file by putting "# feature: no-cq-pattern" as the
first line that the patterns in the file relies on the traditional
behaviour, or "# feature: cq-pattern" to cause the parser to interpret
cquoted patterns, and the last 1.7.x will warn if a file does not have
this explicit marking, but has a pattern that would change the behaviour.
Then 1.8.0 would flip the default.
On Fri, Feb 4, 2011 at 2:03 AM, Junio C Hamano [off-list ref] wrote:
Nguyen Thai Ngoc Duy [off-list ref] writes:
quoted
Migration plan:
I think a release note mentioning this is enough. No migration needed.
But to be safe, we can make post-1.7.5 warn users about patterns with
leading double quote. By 1.8.0, the new behavior will be used.
That's obviously not a migration plan, and it is worse than not having the
warning at all. People with paths that begin with dq (which I suspect
would be an empty set) will get wraning every time they do anything with
git, and until 1.8.0 there is no way to turn that warnings off without
breaking their pattern (like removing the entry from the attributes file),
and when 1.8.0 comes their patterns will break.
Actually they can turn "<dq>abc" pattern to "[<dq>]abc". The tip
should be included in the warning. The warning would then be gone and
their patterns are 1.8.0-safe.
How about introducing a new feature in .gitattributes file so that the
parser can tell if the file is (1) written pre-1.7.5 that depends on the
old behaviour, (2) written post-1.7.5 by a person who is aware of the dq
convention, but still relying on the old behaviour, (3) written post-1.7.5
to take advantage of the new behaviour? E.g., you can explicitly mark
your .gitattributes file by putting "# feature: no-cq-pattern" as the
first line that the patterns in the file relies on the traditional
behaviour, or "# feature: cq-pattern" to cause the parser to interpret
cquoted patterns, and the last 1.7.x will warn if a file does not have
this explicit marking, but has a pattern that would change the behaviour.
Then 1.8.0 would flip the default.
Nice. Chances of having a pattern with leading dq are small enough
that I'd rarely need to add "#feature: cq-pattern" in new
.gitattributes (i.e it does not bother the majority of users).
So the syntax of this line would be:
# feature: <feature>[,<feature>]*
where features in lowercase are mandatory, Git will abort if it does
not understand such a feature. Features start with an uppercase letter
is optional. Hmm?
--
Duy