Re: Bug#553296: gitignore broken completely

Jeff King [off-list ref] 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".