git & patterns

> Hi list
> 
> After reading the manual page for git describe it was not clear to me what
> kind of pattern the --match option should take. Was it to be
> a shell pattern (to be expected) or a regular expression pattern?
> 
> So I dug in the code to find fnmatch: shell pattern.
> 
> Now my question(s):
> - could the manual page be update to make this explicit please? (plus
> other manual pages talking about (shell) patterns)

> I'm using the --match option on git describe to generate version
> information from and matching against a regular expression is soooo much
> more powerful and allows me to fully define my naming convention while
> shell patterns do not allow me to do so.
> 
> Or am I missing something?
> 

> On 05/18/2011 12:48 PM, Ferry Huberts wrote:
>> Hi list
>>
>> After reading the manual page for git describe it was not clear to me what
>> kind of pattern the --match option should take. Was it to be
>> a shell pattern (to be expected) or a regular expression pattern?
>>
>> So I dug in the code to find fnmatch: shell pattern.
>>
>> Now my question(s):
>> - could the manual page be update to make this explicit please? (plus
>> other manual pages talking about (shell) patterns)
> 
> Patches welcome.
> 
>> - could git start taking regular expression patterns please?
>>
> 
> I'm not the maintainer, but with my incredible powers of foresight I'll
> take a wild stab at answering in his stead:
> Not with the current argument, no, but introducing '--rematch' or '--rmatch'
> to take a regular expression instead would probably be a welcome patch if
> it's well done.

> 
> 
>> I'm using the --match option on git describe to generate version
>> information from and matching against a regular expression is soooo much
>> more powerful and allows me to fully define my naming convention while
>> shell patterns do not allow me to do so.
>>
>> Or am I missing something?
>>
> 
> You're not, but we're missing the patch ;)

> After reading the manual page for git describe it was not clear to me what
> kind of pattern the --match option should take. Was it to be
> a shell pattern (to be expected) or a regular expression pattern?
>
> So I dug in the code to find fnmatch: shell pattern.
>
> Now my question(s):
>
> - could the manual page be update to make this explicit please? (plus
> other manual pages talking about (shell) patterns)

> Ferry Huberts <mailings@hupie.com> writes:
> 
>> After reading the manual page for git describe it was not clear to me what
>> kind of pattern the --match option should take. Was it to be
>> a shell pattern (to be expected) or a regular expression pattern?
>>
>> So I dug in the code to find fnmatch: shell pattern.
>>
>> Now my question(s):
>>
>> - could the manual page be update to make this explicit please? (plus
>> other manual pages talking about (shell) patterns)
> 
> The general design guideline we have is to use glob for things that look
> like pathnames. Refs, refspecs, ignore and attribute rules are the
> examples of this rule.
> 

> >> - could the manual page be update to make this explicit please? (plus
> >> other manual pages talking about (shell) patterns)
> >
> > The general design guideline we have is to use glob for things that look
> > like pathnames. Refs, refspecs, ignore and attribute rules are the
> > examples of this rule.
> >
>
> Well, to me tags do not look like pathnames at all, they're just
> 'random' strings. As are branches.
> Technically they may be like pathnames because they're projected on to
> the filesystem that way, but principally they're not IMHO: it's an
> implementation detail.

> > We may be lacking this info in our documentation. A patch to add it
> > somewhere is very welcome.
>
> Yesterday I already did a quick grep on pattern and glob in the
> documentation directory and found that:
> - usually patterns are just patterns, without specifying what kind
> - when a pattern type is specified it most of the time is a glob pattern
> - but sometimes it is called a shell pattern
> - and a few cases speak of a wildcard pattern (I think)
>
> What should it be?
> From your comments I gather it should be a glob pattern.
> Isn't glob too 'tech speak' or is it acceptable?
> If not acceptable, then what? Shell wildcard pattern?

> 
>> Is there a "concepts" or "glossary" man page or similar somewhere that
>> explains all the terms used in git that an "outsider" (somebody who does
>> not develop git and just began to use it) might not be aware of?
> 
> Well, I look like an idiot; I just found the glossary man page.
> 
> However, there is no entry for "glob", or anything about pathnames.
> 

> From: mailings@hupie.com
> On 05/19/2011 08:43 AM, Tim Mazid wrote:
> >
> >> Is there a "concepts" or "glossary" man page or similar somewhere that
> >> explains all the terms used in git that an "outsider" (somebody who does
> >> not develop git and just began to use it) might not be aware of?
> >
> > Well, I look like an idiot; I just found the glossary man page.
> >
> > However, there is no entry for "glob", or anything about pathnames.
> >
>
> Well glob is 'real easy' to find, once you actually know that the code
> calls fnmatch :-) :-)
>
> man fnmatch points to man 7 glob :-)
>
> A regular git user will never know this so adding it to the glossary
> seems a good idea

> Ferry Huberts <mailings@hupie.com> writes:
> 
>> - usually patterns are just patterns, without specifying what kind
> 
>> - when a pattern type is specified it most of the time is a glob pattern
>> - but sometimes it is called a shell pattern
>> - and  a few cases speak of a wildcard pattern (I think)
> 
> All these three are the same thing. I do not personally feel any strong
> need to change a lot of documentation to use only one of the terms, if
> that is what you are getting at.
> 
> What I was wondering was perhaps we may need to document the general
> principle of using globs when matching names that are hierarchically
> grouped with slash-delimited components.
> 
> The branch and tag namespaces are examples of such hiearchically grouped
> namespaces, and it is not a mere implementation detail as you seem to
> think. For jk/blame-line-porcelain and jk/diffstat-binary are both branch
> names, grouped by name initials of the author, and the globbing jk/* is a
> way to get to the group. With that grouping present, you cannot have a
> branch called "jk".