On Wed, Jan 6, 2016 at 8:08 AM, Mostyn Bramley-Moore wrote:
> On 01/04/2016 06:46 PM, Junio C Hamano wrote:
Magic pattern annotation like we do for pathspecs Duy raised may not
be a bad idea, either, and would probably be easier to teach people.
Just like in Perl "(?i)$any_pattern"
On 01/04/2016 06:46 PM, Junio C Hamano wrote:
Mostyn Bramley-Moore writes:
On 12/31/2015 01:23 AM, Junio C Hamano wrote:
...
Swapping the option key and value may not be a bad idea, but one
problem that the above does not solve, which I outlined in the
message you are responding to, is that "
Mostyn Bramley-Moore writes:
> On 12/31/2015 01:23 AM, Junio C Hamano wrote:
> ...
>> Swapping the option key and value may not be a bad idea, but one
>> problem that the above does not solve, which I outlined in the
>> message you are responding to, is that "match-pattern-type" does not
>> give
On 12/31/2015 01:23 AM, Junio C Hamano wrote:
Mostyn Bramley-Moore writes:
OK, brainstorming a bit, how about either of these:
1)
--match-pattern-type=
It's a bit lengthy (maybe --match-type would be sufficient), but I
like that the value names are shared with git grep etc option names.
And
Mostyn Bramley-Moore writes:
> OK, brainstorming a bit, how about either of these:
>
> 1)
> --match-pattern-type=
>
> It's a bit lengthy (maybe --match-type would be sufficient), but I
> like that the value names are shared with git grep etc option names.
> And it seems future-proof- if we ever n
On 12/30/2015 10:52 AM, Duy Nguyen wrote:
What about not using command line options? We could go with something
like pathspec magic. I think as long as we provide three options:
literal, some pattern matching and backquote, then the user has enough
flexibility to specify any set of refs. For patt
On 12/29/2015 07:27 PM, Junio C Hamano wrote:
Mostyn Bramley-Moore writes:
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 ov
On Wed, Dec 30, 2015 at 1:27 AM, Junio C Hamano wrote:
> It is more important to envision what we would do in the future when
> a command that takes a pattern (or a set of patterns) to match the
> refnames with _and_ another pattern (or a set of patterns) to match
> something else, and take that i
Mostyn Bramley-Moore writes:
>> 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
On 12/28/2015 09:30 PM, Junio C Hamano wrote:
Mostyn Bramley-Moore 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 discus
Mostyn Bramley-Moore 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
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
12 matches
Mail list logo
