Re: Bug#553296: gitignore broken completely

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

Jeff King <peff@peff.net> writes:

> I am not sure simply reverting is the best choice; the patch does do
> something useful. And while it strictly breaks backwards compatibility
> on the output without "-i", the old behavior was considered a bug. But
> the "-i" behavior is useless now, so we need to figure out how to
> proceed. We can:
>
>   1. Revert and accept that the behavior is historical. Callers need to
>      work around it by dropping --exclude* when invoking ls-files.
>
>   2. Declare "-i" useless, deprecate and/or remove. Obviously this is
>      also breaking existing behavior, but again, I don't think that
>      using "-i" actually accomplishes anything.
>
>   3. Revert for now, and then reinstate the patch during a major version
>      bump when we are declaring some compatibility breakages.
>
>   4. Re-work "-i" to show tracked but ignored files, but still show all
>      files when "-i" is not given at all.
>
> I think (4) preserves the benefit of the patch in question, but still
> allows your usage ("git ls-files -i --exclude-standard"). I do question
> whether that usage is worth supporting. Certainly I wouldn't implement
> it if I were writing git-ls-files from scratch today, but we do in
> general try to maintain backwards compatibility, especially for plumbing
> like ls-files.
>
> Junio, what do you want to do?

I've never understood the use of "ls-files -i" without -o, so in that
sense, I have done 2. myself already long time ago.

In other words, I do not really care that much, and the choice would be
between "0. do not do anything---the patch in question was a bugfix for
longstanding insanity" and your "4. -i without -o didn't make much sense
but now it does and here is the new meaning".