{"thread":{"id":"27393","subject":"git & patterns","startedAt":"2011-05-18T10:48:34Z","lastAt":"2011-05-19T06:54:50Z","messageCount":11,"participants":["Ferry Huberts","Andreas Ericsson","Junio C Hamano","Tim Mazid"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"168130","messageId":"4DD3A402.3040802@hupie.com","threadId":"27393","inReplyTo":null,"subject":"git & patterns","fromName":"Ferry Huberts","fromEmail":"mailings@hupie.com","sentAt":"2011-05-18T10:48:34Z","receivedAt":"2011-05-18T10:48:34Z","isPatch":false,"sender":{"key":"mailings@hupie.com","avatar":"https://gravatar.com/avatar/ca355376c0713475e17ae413a49f6b98bcbc54cd8364cab7113c53107fb839bb?d=mp&s=160"},"body":"Hi list\n\nAfter reading the manual page for git describe it was not clear to me what\nkind of pattern the --match option should take. Was it to be\na shell pattern (to be expected) or a regular expression pattern?\n\nSo I dug in the code to find fnmatch: shell pattern.\n\nNow my question(s):\n- could the manual page be update to make this explicit please? (plus\nother manual pages talking about (shell) patterns)\n- could git start taking regular expression patterns please?\n\nI'm using the --match option on git describe to generate version\ninformation from and matching against a regular expression is soooo much\nmore powerful and allows me to fully define my naming convention while\nshell patterns do not allow me to do so.\n\nOr am I missing something?\n\ngrtz\n\n-- \nFerry Huberts\n"},{"id":"168134","messageId":"4DD3C484.2070102@op5.se","threadId":"27393","inReplyTo":"4DD3A402.3040802@hupie.com","subject":"Re: git & patterns","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2011-05-18T13:07:16Z","receivedAt":"2011-05-18T13:07:16Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"On 05/18/2011 12:48 PM, Ferry Huberts wrote:\n> Hi list\n> \n> After reading the manual page for git describe it was not clear to me what\n> kind of pattern the --match option should take. Was it to be\n> a shell pattern (to be expected) or a regular expression pattern?\n> \n> So I dug in the code to find fnmatch: shell pattern.\n> \n> Now my question(s):\n> - could the manual page be update to make this explicit please? (plus\n> other manual pages talking about (shell) patterns)\n\nPatches welcome.\n\n> - could git start taking regular expression patterns please?\n> \n\nI'm not the maintainer, but with my incredible powers of foresight I'll\ntake a wild stab at answering in his stead:\nNot with the current argument, no, but introducing '--rematch' or '--rmatch'\nto take a regular expression instead would probably be a welcome patch if\nit's well done.\n\n\n> I'm using the --match option on git describe to generate version\n> information from and matching against a regular expression is soooo much\n> more powerful and allows me to fully define my naming convention while\n> shell patterns do not allow me to do so.\n> \n> Or am I missing something?\n> \n\nYou're not, but we're missing the patch ;)\nFor my own needs, the fnmatch patterns work quite well.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"168137","messageId":"4DD3CB4F.6080304@hupie.com","threadId":"27393","inReplyTo":"4DD3C484.2070102@op5.se","subject":"Re: git & patterns","fromName":"Ferry Huberts","fromEmail":"mailings@hupie.com","sentAt":"2011-05-18T13:36:15Z","receivedAt":"2011-05-18T13:36:15Z","isPatch":false,"sender":{"key":"mailings@hupie.com","avatar":"https://gravatar.com/avatar/ca355376c0713475e17ae413a49f6b98bcbc54cd8364cab7113c53107fb839bb?d=mp&s=160"},"body":"On 05/18/2011 03:07 PM, Andreas Ericsson wrote:\n> On 05/18/2011 12:48 PM, Ferry Huberts wrote:\n>> Hi list\n>>\n>> After reading the manual page for git describe it was not clear to me what\n>> kind of pattern the --match option should take. Was it to be\n>> a shell pattern (to be expected) or a regular expression pattern?\n>>\n>> So I dug in the code to find fnmatch: shell pattern.\n>>\n>> Now my question(s):\n>> - could the manual page be update to make this explicit please? (plus\n>> other manual pages talking about (shell) patterns)\n> \n> Patches welcome.\n> \n>> - could git start taking regular expression patterns please?\n>>\n> \n> I'm not the maintainer, but with my incredible powers of foresight I'll\n> take a wild stab at answering in his stead:\n> Not with the current argument, no, but introducing '--rematch' or '--rmatch'\n> to take a regular expression instead would probably be a welcome patch if\n> it's well done.\n\nagreed\n\n> \n> \n>> I'm using the --match option on git describe to generate version\n>> information from and matching against a regular expression is soooo much\n>> more powerful and allows me to fully define my naming convention while\n>> shell patterns do not allow me to do so.\n>>\n>> Or am I missing something?\n>>\n> \n> You're not, but we're missing the patch ;)\n\nWill see if I can make some time but I'm pretty busy :-(\n\nThanks!\n\n> For my own needs, the fnmatch patterns work quite well.\n> \n\ngrtz\n\n-- \nFerry Huberts\n"},{"id":"168154","messageId":"7vsjsbbx7h.fsf@alter.siamese.dyndns.org","threadId":"27393","inReplyTo":"4DD3A402.3040802@hupie.com","subject":"Re: git & patterns","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-05-18T19:55:14Z","receivedAt":"2011-05-18T19:55:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ferry Huberts writes:\n\n> After reading the manual page for git describe it was not clear to me what\n> kind of pattern the --match option should take. Was it to be\n> a shell pattern (to be expected) or a regular expression pattern?\n>\n> So I dug in the code to find fnmatch: shell pattern.\n>\n> Now my question(s):\n>\n> - could the manual page be update to make this explicit please? (plus\n> other manual pages talking about (shell) patterns)\n\nThe general design guideline we have is to use glob for things that look\nlike pathnames. Refs, refspecs, ignore and attribute rules are the\nexamples of this rule.\n\nWe may be lacking this info in our documentation. A patch to add it\nsomewhere is very welcome.\n"},{"id":"168189","messageId":"4DD4B772.2050404@hupie.com","threadId":"27393","inReplyTo":"7vsjsbbx7h.fsf@alter.siamese.dyndns.org","subject":"Re: git & patterns","fromName":"Ferry Huberts","fromEmail":"mailings@hupie.com","sentAt":"2011-05-19T06:23:46Z","receivedAt":"2011-05-19T06:23:46Z","isPatch":false,"sender":{"key":"mailings@hupie.com","avatar":"https://gravatar.com/avatar/ca355376c0713475e17ae413a49f6b98bcbc54cd8364cab7113c53107fb839bb?d=mp&s=160"},"body":"On 05/18/2011 09:55 PM, Junio C Hamano wrote:\n> Ferry Huberts writes:\n> \n>> After reading the manual page for git describe it was not clear to me what\n>> kind of pattern the --match option should take. Was it to be\n>> a shell pattern (to be expected) or a regular expression pattern?\n>>\n>> So I dug in the code to find fnmatch: shell pattern.\n>>\n>> Now my question(s):\n>>\n>> - could the manual page be update to make this explicit please? (plus\n>> other manual pages talking about (shell) patterns)\n> \n> The general design guideline we have is to use glob for things that look\n> like pathnames. Refs, refspecs, ignore and attribute rules are the\n> examples of this rule.\n> \n\nWell, to me tags do not look like pathnames at all, they're just\n'random' strings. As are branches.\nTechnically they may be like pathnames because they're projected on to\nthe filesystem that way, but principally they're not IMHO: it's an\nimplementation detail.\n\n> We may be lacking this info in our documentation. A patch to add it\n> somewhere is very welcome.\n\nYesterday I already did a quick grep on pattern and glob in the\ndocumentation directory and found that:\n- usually patterns are just patterns, without specifying what kind\n- when a pattern type is specified it most of the time is a glob pattern\n- but sometimes it is called a shell pattern\n- and a few cases speak of a wildcard pattern (I think)\n\nWhat should it be?\nFrom your comments I gather it should be a glob pattern.\nIsn't glob too 'tech speak' or is it acceptable?\nIf not acceptable, then what? Shell wildcard pattern?\n\nthanks!\n\n-- \nFerry Huberts\n"},{"id":"168190","messageId":"SNT124-w95A0758AAE98C128DB9A2C48E0@phx.gbl","threadId":"27393","inReplyTo":"4DD4B772.2050404@hupie.com","subject":"RE: git & patterns","fromName":"Tim Mazid","fromEmail":"timmazid@hotmail.com","sentAt":"2011-05-19T06:40:34Z","receivedAt":"2011-05-19T06:40:34Z","isPatch":false,"sender":{"key":"timmazid@hotmail.com","avatar":null},"body":"\nSorry; just thought I'd chime in as a \"regular\" git user; one who\nactually has to read the documentation to figure things out instead just\nknowing it because they helped code it.\n\n\n> >> - could the manual page be update to make this explicit please? (plus\n> >> other manual pages talking about (shell) patterns)\n> >\n> > The general design guideline we have is to use glob for things that look\n> > like pathnames. Refs, refspecs, ignore and attribute rules are the\n> > examples of this rule.\n> >\n>\n> Well, to me tags do not look like pathnames at all, they're just\n> 'random' strings. As are branches.\n> Technically they may be like pathnames because they're projected on to\n> the filesystem that way, but principally they're not IMHO: it's an\n> implementation detail.\n\nI must agree here. As a non-git-developer, I did not think of tags or \nbranches as pathnames.\n\n\n> > We may be lacking this info in our documentation. A patch to add it\n> > somewhere is very welcome.\n>\n> Yesterday I already did a quick grep on pattern and glob in the\n> documentation directory and found that:\n> - usually patterns are just patterns, without specifying what kind\n> - when a pattern type is specified it most of the time is a glob pattern\n> - but sometimes it is called a shell pattern\n> - and a few cases speak of a wildcard pattern (I think)\n>\n> What should it be?\n> From your comments I gather it should be a glob pattern.\n> Isn't glob too 'tech speak' or is it acceptable?\n> If not acceptable, then what? Shell wildcard pattern?\n\n\nI would not say that glod is too tech speak, as long is it was clearly \nexplained somewhere easily accessible. If it's never explained, or \nburied deep within the manpage for some random command, then it \ncertainly should not be assumed that the reader knows what it is.\n\nSpeaking of which, I'm still not too sure what a glob is.\n\nIs there a \"concepts\" or \"glossary\" man page or similar somewhere that \nexplains all the terms used in git that an \"outsider\" (somebody who does\nnot develop git and just began to use it) might not be aware of?\n\nIf there is not, might I suggest it be a good idea to include one as \nwell references to it so that a rookie will know they should look there\nfor explanations of terms?\n\n\nTim.\n\n() ascii ribbon campaign - against html e-mail\n/\\ www.asciiribbon.org - against proprietary attachments\n \t\t \t \t\t "},{"id":"168192","messageId":"SNT124-W45CEA4AD8A3564C9F78071C48E0@phx.gbl","threadId":"27393","inReplyTo":"SNT124-w95A0758AAE98C128DB9A2C48E0@phx.gbl","subject":"RE: git & patterns","fromName":"Tim Mazid","fromEmail":"timmazid@hotmail.com","sentAt":"2011-05-19T06:43:39Z","receivedAt":"2011-05-19T06:43:39Z","isPatch":false,"sender":{"key":"timmazid@hotmail.com","avatar":null},"body":"\n> Is there a \"concepts\" or \"glossary\" man page or similar somewhere that\n> explains all the terms used in git that an \"outsider\" (somebody who does\n> not develop git and just began to use it) might not be aware of?\n\nWell, I look like an idiot; I just found the glossary man page.\n\nHowever, there is no entry for \"glob\", or anything about pathnames.\n\n\n() ascii ribbon campaign - against html e-mail\n/\\ www.asciiribbon.org - against proprietary attachments\n \t\t \t \t\t "},{"id":"168193","messageId":"4DD4BCB2.5080309@hupie.com","threadId":"27393","inReplyTo":"SNT124-W45CEA4AD8A3564C9F78071C48E0@phx.gbl","subject":"Re: git & patterns","fromName":"Ferry Huberts","fromEmail":"mailings@hupie.com","sentAt":"2011-05-19T06:46:10Z","receivedAt":"2011-05-19T06:46:10Z","isPatch":false,"sender":{"key":"mailings@hupie.com","avatar":"https://gravatar.com/avatar/ca355376c0713475e17ae413a49f6b98bcbc54cd8364cab7113c53107fb839bb?d=mp&s=160"},"body":"On 05/19/2011 08:43 AM, Tim Mazid wrote:\n> \n>> Is there a \"concepts\" or \"glossary\" man page or similar somewhere that\n>> explains all the terms used in git that an \"outsider\" (somebody who does\n>> not develop git and just began to use it) might not be aware of?\n> \n> Well, I look like an idiot; I just found the glossary man page.\n> \n> However, there is no entry for \"glob\", or anything about pathnames.\n> \n\nWell glob is 'real easy' to find, once you actually know that the code\ncalls fnmatch :-) :-)\n\nman fnmatch points to man 7 glob :-)\n\nA regular git user will never know this so adding it to the glossary\nseems a good idea\n\n-- \nFerry Huberts\n"},{"id":"168194","messageId":"7v62p79og8.fsf@alter.siamese.dyndns.org","threadId":"27393","inReplyTo":"4DD4B772.2050404@hupie.com","subject":"Re: git & patterns","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-05-19T06:47:19Z","receivedAt":"2011-05-19T06:47:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ferry Huberts writes:\n\n> - usually patterns are just patterns, without specifying what kind\n\n> - when a pattern type is specified it most of the time is a glob pattern\n> - but sometimes it is called a shell pattern\n> - and a few cases speak of a wildcard pattern (I think)\n\nAll these three are the same thing. I do not personally feel any strong\nneed to change a lot of documentation to use only one of the terms, if\nthat is what you are getting at.\n\nWhat I was wondering was perhaps we may need to document the general\nprinciple of using globs when matching names that are hierarchically\ngrouped with slash-delimited components.\n\nThe branch and tag namespaces are examples of such hiearchically grouped\nnamespaces, and it is not a mere implementation detail as you seem to\nthink. For jk/blame-line-porcelain and jk/diffstat-binary are both branch\nnames, grouped by name initials of the author, and the globbing jk/* is a\nway to get to the group. With that grouping present, you cannot have a\nbranch called \"jk\".\n"},{"id":"168197","messageId":"SNT124-W262001D726480B1E78D059C48E0@phx.gbl","threadId":"27393","inReplyTo":"4DD4BCB2.5080309@hupie.com","subject":"RE: git & patterns","fromName":"Tim Mazid","fromEmail":"timmazid@hotmail.com","sentAt":"2011-05-19T06:54:04Z","receivedAt":"2011-05-19T06:54:04Z","isPatch":false,"sender":{"key":"timmazid@hotmail.com","avatar":null},"body":"\n> From: mailings@hupie.com\n> On 05/19/2011 08:43 AM, Tim Mazid wrote:\n> >\n> >> Is there a \"concepts\" or \"glossary\" man page or similar somewhere that\n> >> explains all the terms used in git that an \"outsider\" (somebody who does\n> >> not develop git and just began to use it) might not be aware of?\n> >\n> > Well, I look like an idiot; I just found the glossary man page.\n> >\n> > However, there is no entry for \"glob\", or anything about pathnames.\n> >\n>\n> Well glob is 'real easy' to find, once you actually know that the code\n> calls fnmatch :-) :-)\n>\n> man fnmatch points to man 7 glob :-)\n>\n> A regular git user will never know this so adding it to the glossary\n> seems a good idea\n\nYes... I was merely demonstrating a point... I knew that all along... >.>\n\nOnto the glossary, though; I did not even know it existed until just now \nwhen I tried to look for it. Nothing ever told me \"if you're confused\nabout anything, go 'git help glossary'\". I don't think it was ever in\nthe \"see also\" sections of other pages.\n\nOut of curiosity, did Linus/Junio write the majority of the \ndocumentation? I know it is difficult to write documentation for those\nwho don't know once you already know what is going on.\n\n\n() ascii ribbon campaign - against html e-mail\n/\\ www.asciiribbon.org - against proprietary attachments\n \t\t \t \t\t "},{"id":"168198","messageId":"4DD4BEBA.7010000@hupie.com","threadId":"27393","inReplyTo":"7v62p79og8.fsf@alter.siamese.dyndns.org","subject":"Re: git & patterns","fromName":"Ferry Huberts","fromEmail":"mailings@hupie.com","sentAt":"2011-05-19T06:54:50Z","receivedAt":"2011-05-19T06:54:50Z","isPatch":false,"sender":{"key":"mailings@hupie.com","avatar":"https://gravatar.com/avatar/ca355376c0713475e17ae413a49f6b98bcbc54cd8364cab7113c53107fb839bb?d=mp&s=160"},"body":"On 05/19/2011 08:47 AM, Junio C Hamano wrote:\n> Ferry Huberts writes:\n> \n>> - usually patterns are just patterns, without specifying what kind\n> \n>> - when a pattern type is specified it most of the time is a glob pattern\n>> - but sometimes it is called a shell pattern\n>> - and a few cases speak of a wildcard pattern (I think)\n> \n> All these three are the same thing. I do not personally feel any strong\n> need to change a lot of documentation to use only one of the terms, if\n> that is what you are getting at.\n> \n> What I was wondering was perhaps we may need to document the general\n> principle of using globs when matching names that are hierarchically\n> grouped with slash-delimited components.\n> \n> The branch and tag namespaces are examples of such hiearchically grouped\n> namespaces, and it is not a mere implementation detail as you seem to\n> think. For jk/blame-line-porcelain and jk/diffstat-binary are both branch\n> names, grouped by name initials of the author, and the globbing jk/* is a\n> way to get to the group. With that grouping present, you cannot have a\n> branch called \"jk\".\n\nI would just argue that you layered a grouping abstraction (jk/*) on top\nof something (branch and tag names) that is _conceptually_ _not_ like a path\n\nI understand your reluctance but try to take a step back: _conceptually_\nbranches and tags are not paths\n\nI don't want to push my case though :-)\n\n-- \nFerry Huberts\n"}]}