Duy Nguyen writes:
> On Fri, Jan 25, 2013 at 1:22 AM, Junio C Hamano wrote:
>> Duy Nguyen writes:
>>
>>> I don't think we need to support two different sets of wildcards in
>>> the long run. I'm thinking of adding ":(glob)" with WM_PATHNAME.
>>> Pathspec without :(glob) still uses the current w
On Fri, Jan 25, 2013 at 1:22 AM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> I don't think we need to support two different sets of wildcards in
>> the long run. I'm thinking of adding ":(glob)" with WM_PATHNAME.
>> Pathspec without :(glob) still uses the current wildcards (i.e. no
>> FNM_PAT
Duy Nguyen writes:
> I don't think we need to support two different sets of wildcards in
> the long run. I'm thinking of adding ":(glob)" with WM_PATHNAME.
> Pathspec without :(glob) still uses the current wildcards (i.e. no
> FNM_PATHNAME). At some point, like 2.0, we either switch the behavior
On Thu, Jan 24, 2013 at 11:49 AM, Junio C Hamano wrote:
>> The only problem I see is, without the version string, there's no way
>> to know if "**" is supported. Old git versions will happily take "**"
>> and interpret as "*". When you advise someone to use "**" you might
>> need to add "check if
Duy Nguyen writes:
> If we do that, we need to do the same in tree_entry_interesting(). In
> other words, pathspec learns the new glob syntax. It's fine for an
> experimental flag like USE_WILDMATCH. But after fnmatch is replaced by
> wildmatch unconditionally (thus USE_WILDMATCH becomes obsolete
On Wed, Jan 23, 2013 at 5:51 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> We obviously do not want to set FNM_PATHNAME when we are not
>> substituting fnmatch() with wildmatch(), but I wonder if it may make
>> sense to unconditionally use WM_PATHNAME semantics when we build the
>> syst
Junio C Hamano writes:
> We obviously do not want to set FNM_PATHNAME when we are not
> substituting fnmatch() with wildmatch(), but I wonder if it may make
> sense to unconditionally use WM_PATHNAME semantics when we build the
> system with USE_WILDMATCH and calling wildmatch() in this codepath.
Nguyễn Thái Ngọc Duy writes:
> "**" is adjusted to only be effective when surrounded by slashes, in
> 40bbee0 (wildmatch: adjust "**" behavior - 2012-10-15). Except that
> the commit did it wrong:
>
> 1. when it checks for "the preceding slash unless ** is at the
>beginning", it compares to
"**" is adjusted to only be effective when surrounded by slashes, in
40bbee0 (wildmatch: adjust "**" behavior - 2012-10-15). Except that
the commit did it wrong:
1. when it checks for "the preceding slash unless ** is at the
beginning", it compares to wrong pointer. It should have compared
t
9 matches
Mail list logo
