From: Mostyn Bramley-Moore <mostynb@opera.com>
Date: Tue, 29 Dec 2015 00:13:32 GMT
Subject: Re: [PATCH/RFC v2 0/2] add regex match flags to git describe
Message-ID: <5681D02C.1040609@opera.com>
In-Reply-To: <xmqqy4cejoz4.fsf@gitster.mtv.corp.google.com>

On 12/28/2015 09:30 PM, Junio C Hamano wrote:
> Mostyn Bramley-Moore <mostynb@opera.com> writes:
>
>> git describe currently only supports glob matching with the --matches flag.
>> It would be useful to support regular expressions.
>>
>> For consistency, this uses the same regex flags as those used by git-grep.
>>
>> Some old discussion of this as a candidate feature is here, though nobody put
>> together a patch as far as I can see:
>> http://comments.gmane.org/gmane.comp.version-control.git/173873
>
> Thanks.
>
> I do not think it is wrong per-se to add an option to use regular
> expressions instead of globs, but if we are to do so, the endgame we
> aim for MUST be that we do so consistently to all the other commands
> that iterate over refs and limit their output to the ones that match
> given pattern (or a set of patterns), not just 'describe'.

There is one important distinction between 'git describe' and the other 
commands that iterate through refs- it applies an internal search 
strategy and outputs at most one match.  This makes it difficult to 
search for the closest matching tag that matches any item in a set of 
patterns without some messy scripting (ie run multiple 'git describe' 
commands, for each pattern, then figure out which result is the one you 
want).

> Even if we are not adding such an option to these other commands
> right now (yet), we at least need to know what these commands are
> (e.g. "git tag -l" and "git for-each-ref" immediately come to mind,
> but there may be others), and make sure that the option names you
> choose here can be used sensibly in their context.  I think "tag"
> and "for-each-ref" do no pattern matching against anything other
> than the refnames, so it would be clear what a new --perl-regexp
> option does in their contexts.

The commands that you mention produce a list of results, which can 
easily be processed by an external util (eg grep itself), and might not 
need similar arguments to be added.

Adding regex pattern matching to 'git describe' is just one reasonable 
(IMO) solution, but there are a couple of alternatives that might suffice:
1) Add an option to print all tags, in a well-defined/useful order. 
Then the results would be easy to process by an external command too.
2) Add support for multiple patterns, and print the first found item 
that matches any of them.

> Unlike "grep" whose sole point is to perform pattern matching, the
> filtering of refs these commands do is merely a very small tweak in
> the overall picture (e.g. "git tag --contains $commit -l $pattern"
> does filter by matching $pattern against the refname, but that is a
> small detail compared to the filtering done by the reachability with
> the $commit), so I am not sure if short -E/-G/-F/-P should be given
> to these commands like "grep" does, though.  These commands may have
> better uses for these shorter option names.

Besides 'git grep', the only regex type flag that is given a short 
option seems to be -E for 'git log' and 'git rev-list'.  I have no 
objection to dropping the short options, or leaving only -E.


-Mostyn.
-- 
Mostyn Bramley-Moore
TV and Connected Devices
Opera Software ASA
mostynb@opera.com