Re: Bug#553296: gitignore broken completely
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Oct 30, 2009, 19:41 UTC
- Message-ID
- <7vaaz8lleg.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <20091030173838.GB18583@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 27 quoted lines
> 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".