Nguyen Thai Ngoc Duy [off-list ref] writes:
On Sat, May 26, 2012 at 11:30 AM, Nguyen Thai Ngoc Duy
[off-list ref] wrote:
quoted
On Sat, May 26, 2012 at 12:32 AM, Junio C Hamano [off-list ref] wrote:
quoted
Nguyễn Thái Ngọc Duy [off-list ref] writes:
quoted
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.
Hi Guy's,
Seeing the discussion about the interpretation of '/' - I would like to add some additional support for my case that it should represent the contents of the top level dir:
If I do "ls /" on a unix system - I get a list of the contents of the root of the files system, I think we should maintain this in git, such that '/' represents the top of the tree rather than suppressing it.
Best Regards,
Caleb
Caleb Marchent, Software Developer, Amino Communications Ltd, Buckingway Business Park, Anderson Road, Swavesey, Cambridge, CB24 4UQ, UK cmarchent@aminocom.com www.aminocom.com
Tel: +44 1954 234 100
________________________________________
From: git-owner@vger.kernel.org [git-owner@vger.kernel.org] on behalf of Junio C Hamano [gitster@pobox.com]
Sent: 03 June 2012 22:49
To: Nguyen Thai Ngoc Duy
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Teach ignore machinery about pattern "/"
Nguyen Thai Ngoc Duy [off-list ref] writes:
On Sat, May 26, 2012 at 11:30 AM, Nguyen Thai Ngoc Duy
[off-list ref] wrote:
quoted
On Sat, May 26, 2012 at 12:32 AM, Junio C Hamano [off-list ref] wrote:
quoted
Nguyễn Thái Ngọc Duy [off-list ref] writes:
quoted
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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html