Re: Bug#553296: gitignore broken completely

From: Jeff King <peff@peff.net>
Date: Oct 30, 2009, 18:41 UTC
Message-ID: <20091030184155.GC19901@coredump.intra.peff.net>
In-Reply-To: <20091030182331.GC10671@ikki.ethgen.de>

On Fri, Oct 30, 2009 at 07:23:31PM +0100, Klaus Ethgen wrote:

> Well ls-files is used to see such broken files. (Another example is if
> you accidentally add a file which you (later) decide to be ignored. You
> will have no change to find that files at all anymore.) With the patch
> that use case of ls-files has been gone without a replacement.

I think your reasoning is a little bit circular. They are not actually broken with respect to git. But they might represent an error on the part of the programmer, and one which they would want to investigate. You could also catch it by looking at diffs ("why is this file in my diff, it is supposed to be ignored"), but I am not opposed to accessing the information via git-ls-files (and I think you are right that the query cannot be easily done any other way).

Show 6 quoted lines

> I have two more options:
> 
>    5. Revert the patch and rework it to have a option to ignore or
>       respect the excluded files (Such as --use-excludes for example) or
>       respect them anyway if a --exclude* option is given on command
>       line.

I think that is basically equivalent to (1). There is already a way for callers to avoid the bug, which is not to provide --exclude* at all. So you are already setting that one bit of information in whether or not you provide any excludes.

>    6. Revert the patch and rework it so that it will only have effect if
>       there is no -i option on the command line. (That is similiar to a
>       mix of 3 and 4.)

Yeah, that would actually be the least invasive change, and would keep "-i" just as it is. If we do anything except a simple, I think your (6) makes the most sense.

Let me see if I can make a patch.

-Peff