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@xxxxxxxxxxxx www.aminocom.com Tel: +44 1954 234 100 ________________________________________ From: git-owner@xxxxxxxxxxxxxxx [git-owner@xxxxxxxxxxxxxxx] on behalf of Junio C Hamano [gitster@xxxxxxxxx] Sent: 03 June 2012 22:49 To: Nguyen Thai Ngoc Duy Cc: git@xxxxxxxxxxxxxxx Subject: Re: [PATCH] Teach ignore machinery about pattern "/" Nguyen Thai Ngoc Duy <pclouds@xxxxxxxxx> writes: > On Sat, May 26, 2012 at 11:30 AM, Nguyen Thai Ngoc Duy > <pclouds@xxxxxxxxx> wrote: >> On Sat, May 26, 2012 at 12:32 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >>> Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html ��.n��������+%������w��{.n��������n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�