{"thread":{"id":"26398","subject":"[1.8.0] Support quoting in .gitattributes, .gitignore","startedAt":"2011-02-03T11:51:18Z","lastAt":"2011-02-04T13:17:01Z","messageCount":3,"participants":["Nguyen Thai Ngoc Duy","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"160324","messageId":"AANLkTikHNKmcapVWBAcufq8ONVWOWHbnL-H8Nf2WmKM5@mail.gmail.com","threadId":"26398","inReplyTo":null,"subject":"[1.8.0] Support quoting in .gitattributes, .gitignore","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-02-03T11:51:18Z","receivedAt":"2011-02-03T11:51:18Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"Proposal:\n\nThere's already a patch for .gitattributes [1].\n\nTo summarize: .gitattributes separates pattern and attributes by\nspaces, therefore spaces could not be present in patterns. There are\ntricks to overcome (e.g. substitute spaces with dots) but it's well..\ntricky. The patch adds support for quoting full patterns.\n\nWhile .gitignore does not have the same problem, it'd be nice to\nsupport quoting too for a few reasons:\n\n - Keep differences between gitattr and gitignore to minimum. A\nhero(ine) might come and unify them some day. Don't make his/her work\nharder.\n - Is ability to put \\n in patterns counted as a good point?\n\nRisks:\n\nCurrent patterns with leading double quote mark will be\nmisinterpreted. Though chances are really small.\n\nMigration plan:\n\nI think a release note mentioning this is enough. No migration needed.\n\nBut to be safe, we can make post-1.7.5 warn users about patterns with\nleading double quote. By 1.8.0, the new behavior will be used.\n\n[1] http://article.gmane.org/gmane.comp.version-control.git/160867\n-- \nDuy\n"},{"id":"160344","messageId":"7vbp2t0wld.fsf@alter.siamese.dyndns.org","threadId":"26398","inReplyTo":"AANLkTikHNKmcapVWBAcufq8ONVWOWHbnL-H8Nf2WmKM5@mail.gmail.com","subject":"Re: [1.8.0] Support quoting in .gitattributes, .gitignore","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-03T19:03:26Z","receivedAt":"2011-02-03T19:03:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nguyen Thai Ngoc Duy writes:\n\n> Migration plan:\n>\n> I think a release note mentioning this is enough. No migration needed.\n>\n> But to be safe, we can make post-1.7.5 warn users about patterns with\n> leading double quote. By 1.8.0, the new behavior will be used.\n\nThat's obviously not a migration plan, and it is worse than not having the\nwarning at all. People with paths that begin with dq (which I suspect\nwould be an empty set) will get wraning every time they do anything with\ngit, and until 1.8.0 there is no way to turn that warnings off without\nbreaking their pattern (like removing the entry from the attributes file),\nand when 1.8.0 comes their patterns will break.\n\nHow about introducing a new feature in .gitattributes file so that the\nparser can tell if the file is (1) written pre-1.7.5 that depends on the\nold behaviour, (2) written post-1.7.5 by a person who is aware of the dq\nconvention, but still relying on the old behaviour, (3) written post-1.7.5\nto take advantage of the new behaviour? E.g., you can explicitly mark\nyour .gitattributes file by putting \"# feature: no-cq-pattern\" as the\nfirst line that the patterns in the file relies on the traditional\nbehaviour, or \"# feature: cq-pattern\" to cause the parser to interpret\ncquoted patterns, and the last 1.7.x will warn if a file does not have\nthis explicit marking, but has a pattern that would change the behaviour.\nThen 1.8.0 would flip the default.\n"},{"id":"160395","messageId":"AANLkTi=0wrCVLetPsDGQAMYupfULFi6k2JijDnJQXPbO@mail.gmail.com","threadId":"26398","inReplyTo":"7vbp2t0wld.fsf@alter.siamese.dyndns.org","subject":"Re: [1.8.0] Support quoting in .gitattributes, .gitignore","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-02-04T13:17:01Z","receivedAt":"2011-02-04T13:17:01Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Fri, Feb 4, 2011 at 2:03 AM, Junio C Hamano wrote:\n> Nguyen Thai Ngoc Duy writes:\n>\n>> Migration plan:\n>>\n>> I think a release note mentioning this is enough. No migration needed.\n>>\n>> But to be safe, we can make post-1.7.5 warn users about patterns with\n>> leading double quote. By 1.8.0, the new behavior will be used.\n>\n> That's obviously not a migration plan, and it is worse than not having the\n> warning at all.  People with paths that begin with dq (which I suspect\n> would be an empty set) will get wraning every time they do anything with\n> git, and until 1.8.0 there is no way to turn that warnings off without\n> breaking their pattern (like removing the entry from the attributes file),\n> and when 1.8.0 comes their patterns will break.\n\nActually they can turn \"abc\" pattern to \"[]abc\". The tip\nshould be included in the warning. The warning would then be gone and\ntheir patterns are 1.8.0-safe.\n\n> How about introducing a new feature in .gitattributes file so that the\n> parser can tell if the file is (1) written pre-1.7.5 that depends on the\n> old behaviour, (2) written post-1.7.5 by a person who is aware of the dq\n> convention, but still relying on the old behaviour, (3) written post-1.7.5\n> to take advantage of the new behaviour?  E.g., you can explicitly mark\n> your .gitattributes file by putting \"# feature: no-cq-pattern\" as the\n> first line that the patterns in the file relies on the traditional\n> behaviour, or \"# feature: cq-pattern\" to cause the parser to interpret\n> cquoted patterns, and the last 1.7.x will warn if a file does not have\n> this explicit marking, but has a pattern that would change the behaviour.\n> Then 1.8.0 would flip the default.\n\nNice. Chances of having a pattern with leading dq are small enough\nthat I'd rarely need to add \"#feature: cq-pattern\" in new\n.gitattributes (i.e it does not bother the majority of users).\n\nSo the syntax of this line would be:\n\n# feature: [,]*\n\nwhere features in lowercase are mandatory, Git will abort if it does\nnot understand such a feature. Features start with an uppercase letter\nis optional. Hmm?\n-- \nDuy\n"}]}