threads / discuss / 26398

[1.8.0] Support quoting in .gitattributes, .gitignore

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

## tl;dr

3 messages between Feb 3, 2011 and Feb 4, 2011.

replies: 2people: 2as markdown or json

Nguyen Thai Ngoc Duy· Feb 3, 2011, 11:51 UTC · lore

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

Junio C Hamano· Feb 3, 2011, 19:03 UTC · re: Nguyen Thai Ngoc Duy · lore

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

Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:

Show 6 quoted lines

> 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.

Nguyen Thai Ngoc Duy· Feb 4, 2011, 13:17 UTC · re: Junio C Hamano · lore

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

On Fri, Feb 4, 2011 at 2:03 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 15 quoted lines

> 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.

Show 11 quoted lines

> 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