Re: Bug in .gitignore handling

[Junio C Hamano <gitster@pobox.com>]

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

> 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.