[1.8.0] Support quoting in .gitattributes, .gitignore

[1.8.0] Support quoting in .gitattributes, .gitignore

[Nguyen Thai Ngoc Duy]

Proposal:

There's already a patch for .gitattributes [1].

To summarize: .gitattributes separates pattern and attributes by
spaces, therefore spaces could not be present in patterns. There are
tricks to overcome (e.g. substitute spaces with dots) but it's well..
tricky. The patch adds support for quoting full patterns.

While .gitignore does not have the same problem, it'd be nice to
support quoting too for a few reasons:

 - Keep differences between gitattr and gitignore to minimum. A
hero(ine) might come and unify them some day. Don't make his/her work
harder.
 - Is ability to put \n in patterns counted as a good point?

Risks:

Current patterns with leading double quote mark will be
misinterpreted. Though chances are really small.

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.

[1] http://article.gmane.org/gmane.comp.version-control.git/160867
-- 
Duy

Re: [1.8.0] Support quoting in .gitattributes, .gitignore

[Junio C Hamano]

Nguyen Thai Ngoc Duy <pclouds@gmail.com> 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.

Re: [1.8.0] Support quoting in .gitattributes, .gitignore

[Nguyen Thai Ngoc Duy]

On Fri, Feb 4, 2011 at 2:03 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> 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.

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