.gitignore Bug Report on the behavior of *

I'm not sure if this is a documentation bug, an actual bug, or my mis-interpretation of what is supposed to happen, however, this behavior was not expected by other people as well. This was tested using git 1.7.2.3 and 1.7.3

My sample configuration: ---------------------------------------------------------------------- mkdir foo; cd foo; git init; echo A > A; mkdir B; echo B > B/B git add .; git commit -a -m "initial" ----------------------------------------------------------------------

# Properly shows X and B/XX as untracked, as I expected echo X > X; echo XX > B/XX; git status

# I expected B/XX to show up as untracked rm -f .gitignore B/.gitignore echo '*' > .gitignore; echo '!*' > B/.gitignore; git status

# I expected B/XX to show up as untracked rm -f .gitignore B/.gitignore echo '/*' > .gitignore; git status

# Works as I expected rm -f .gitignore B/.gitignore echo '/*X' > .gitignore; git status

# Works as I expected rm -f .gitignore B/.gitignore echo '*X' > .gitignore; echo '!*X' > B/.gitignore; git status

# Works as I expected rm -f .gitignore B/.gitignore echo -e '/*\n!/B' > .gitignore; git status

					-Seth Robertson

On Samstag, 25. September 2010, Seth Robertson wrote:

You should update your expectations to match what you got. ;-)

To show why your expectations are wrong, consider a *huge* and *deep* directory with thousands and thousands of subdirectories, call it "usr", that should be ignored. The .gitignore at the top-level would just say:

  /usr

Do you really expect git to walk down this ignored directory, just to make double-sure that really, really down there does nowhere exist a .gitignore that says "oh, wait, don't ignore *this* file"?

-- Hannes

In message <201009252203.48820.j6t@kdbg.org>, Johannes Sixt writes:

    On Samstag, 25. September 2010, Seth Robertson wrote:
    > # Properly shows X and B/XX as untracked, as I expected
    > echo X > X; echo XX > B/XX; git status
    >
    > # I expected B/XX to show up as untracked
    > rm -f .gitignore B/.gitignore
    > echo '*' > .gitignore; echo '!*' > B/.gitignore; git status

    You should update your expectations to match what you got. ;-)

    To show why your expectations are wrong, consider a *huge* and
    *deep* directory with thousands and thousands of subdirectories,
    call it "usr", that should be ignored. The .gitignore at the
    top-level would just say:

      /usr

    Do you really expect git to walk down this ignored directory, just to make
    double-sure that really, really down there does nowhere exist a .gitignore
    that says "oh, wait, don't ignore *this* file"?

Hmm. No, not really, but having a .gitignore in a directory which has tracked git files in it seems somehow different, and at least to me the documentation of .gitignore suggests a different algorithm. How about this for a documentation patch?

Signed-off-by: Seth Robertson <in-gitvger@baka.org>
----------------------------------------------------------------------

On Sat, Sep 25, 2010 at 20:03, Johannes Sixt <j6t@kdbg.org> wrote:

That wouldn't be so expensive if the expectation that the .gitignore in /usr would only be considered if it had already been commited. Then we'd just have to check if we have a tree for /usr, and whether there's a gitignore there.

But doing this in the top-level .gitignore if possible is the best solution.

Heya,

<threadjacking rant>

On Sat, Sep 25, 2010 at 22:03, Johannes Sixt <j6t@kdbg.org> wrote:

Yet when I (recursively for all files) 'git update-index --assume-unchanged some-dir' it will still looking at all the bloody .gitignore making it slow as moleasses.

</rant>

Of course, the above is an insane setup with a .gitignore file in each and every directory. But it would be so nice if git Just Worked even in insane cases!