Re: [PATCH] Teach ignore machinery about pattern "/"

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 3, 2012, 21:49 UTC
Message-ID: <7vbol0xdzj.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CACsJy8BSHFzGfsm6qY1LEX9wubKjKXXbJ_WMAiOAUhVGa631Ag@mail.gmail.com>

Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:

Show 16 quoted lines

> On Sat, May 26, 2012 at 11:30 AM, Nguyen Thai Ngoc Duy
> <pclouds@gmail.com> wrote:
>> On Sat, May 26, 2012 at 12:32 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Nguyễn Thái Ngọc Duy  <pclouds@gmail.com> writes:
>>>
>>>> Pattern "/" is ambiguous because the slash can mean "anchor the
>>>> pattern to this location" (e.g. /path), but it can also mean
>>>> "match directories only" (e.g. path/). Currently git interprets it as
>>>> the latter except that 'path' is an empty string, which makes this
>>>> pattern totally useless.
>>>
>>> Did the old version interprete it as the former?
>>
>> That calls for bit of testing, which I'll do soon.
>
> "/" is no-op since 1.4.0 (tested with refs/tags/v*),...

So historically we had three possible interpretations of "/", i.e. "/path" that happens to have an empty path, "path/" that happens to have an empty path, and a no-op.

That strongly suggests that we should at least warn when we see "/" that the user is playing with fire by feeding the exclude machinery something without clear semantics.

Doing a no-op might be a safer option than adding it new special case semantics to it, but even then I do not think we should silently ignore it. Silently giving new semantics for this particular special case is out of the question, I would have to say.

Thanks for digging.