Re: Bug in .gitignore handling

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 26, 2008, 20:20 UTC
Message-ID: <7vhcetck5m.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <47EAABB6.30803@thorn.ws>

Tommy Thorn <tommy-git@thorn.ws> writes:

Show 9 quoted lines

> According to the man page, I should be able to change .gitignore to
> "foo/" to stop it from looking recursively, but that doesn't work, as
> now git clean -n -f -d wants to remove mydir/foo but not mydir/foo/objs
>
> My desperate attempts "./foo" and "^foo" also didn't work. Please note
> that this is a vastly simplified version of the real problem, so I
> can't just use "!mousetrap/foo".
>
> It seems "foo/" _should_ work even though foo isn't a directory.

Are you talking about d6b8fc3 (gitignore(5): Allow "foo/" in ignore list to match directory "foo", 2008-01-31), specifically this part of the manual?

    diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
    index 08373f5..e847b3b 100644
    --- a/Documentation/gitignore.txt
    +++ b/Documentation/gitignore.txt
    @@ -57,6 +57,13 @@ Patterns have the following format:
        included again.  If a negated pattern matches, this will
        override lower precedence patterns sources.

    + - If the pattern ends with a slash, it is removed for the
    +   purpose of the following description, but it would only find
    +   a match with a directory.  In other words, `foo/` will match a
    +   directory `foo` and paths underneath it, but will not match a
    +   regular file or a symbolic link `foo` (this is consistent
    +   with the way how pathspec works in general in git).
    +
      - If the pattern does not contain a slash '/', git treats it as
        a shell glob pattern and checks for a match against the
        pathname without leading directories.

Incidentally I notice that the above patch did not include new tests to see if "git clean" honors the corrected pattern matching rule. If your "real problem" is too complex to describe, perhaps an additional test that exercises "git clean" with test_expect_failure would help motivated parties to triage and fix the problem.

"git clean" has always been an ugly and unreliable stepchild, and I would not be surprised at all if it is ridden with corner case bugs, especially around the area to skip untracked directories; but in this case you are not dealing with a directory but a symlink, and it should not get confused by the fact that the symlink happens to point at a directory.