Jeff King <p...@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". -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org