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