git & patterns

git & patterns

[Ferry Huberts]

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)
- could git start taking regular expression patterns please?

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?

grtz

-- 
Ferry Huberts

Re: git & patterns

[Andreas Ericsson]

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 ;)
For my own needs, the fnmatch patterns work quite well.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: git & patterns

[Ferry Huberts]

On 05/18/2011 03:07 PM, Andreas Ericsson wrote:
> 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.

agreed

> 
> 
>> 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 ;)

Will see if I can make some time but I'm pretty busy :-(

Thanks!

> For my own needs, the fnmatch patterns work quite well.
> 

grtz

-- 
Ferry Huberts

Re: git & patterns

[Junio C Hamano]

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.

We may be lacking this info in our documentation. A patch to add it
somewhere is very welcome.

Re: git & patterns

[Ferry Huberts]

On 05/18/2011 09:55 PM, Junio C Hamano wrote:
> 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.
> 

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?

thanks!

-- 
Ferry Huberts

RE: git & patterns

[Tim Mazid]

Sorry; just thought I'd chime in as a "regular" git user; one who
actually has to read the documentation to figure things out instead just
knowing it because they helped code it.


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

I must agree here. As a non-git-developer, I did not think of tags or 
branches as pathnames.


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


I would not say that glod is too tech speak, as long is it was clearly 
explained somewhere easily accessible. If it's never explained, or 
buried deep within the manpage for some random command, then it 
certainly should not be assumed that the reader knows what it is.

Speaking of which, I'm still not too sure what a glob is.

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?

If there is not, might I suggest it be a good idea to include one as 
well references to it so that a rookie will know they should look there
for explanations of terms?


Tim.

() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
 		 	   		  

RE: git & patterns

[Tim Mazid]

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


() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
 		 	   		  

Re: git & patterns

[Ferry Huberts]

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

RE: git & patterns

[Tim Mazid]

> 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

Yes... I was merely demonstrating a point... I knew that all along... >.>

Onto the glossary, though; I did not even know it existed until just now 
when I tried to look for it. Nothing ever told me "if you're confused
about anything, go 'git help glossary'". I don't think it was ever in
the "see also" sections of other pages.

Out of curiosity, did Linus/Junio write the majority of the 
documentation? I know it is difficult to write documentation for those
who don't know once you already know what is going on.


() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
 		 	   		  

Re: git & patterns

[Junio C Hamano]

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

Re: git & patterns

[Ferry Huberts]

On 05/19/2011 08:47 AM, Junio C Hamano wrote:
> 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".

I would just argue that you layered a grouping abstraction (jk/*) on top
of something (branch and tag names) that is _conceptually_ _not_ like a path

I understand your reluctance but try to take a step back: _conceptually_
branches and tags are not paths

I don't want to push my case though :-)

-- 
Ferry Huberts