Re: [PATCH] git-diff: Add --staged as a synonym for --cached.
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Nov 2, 2008, 18:30 UTC
- Message-ID
- <7vljw2yo93.fsf@gitster.siamese.dyndns.org>
- In-Reply-To
- <20081102123519.GA21251@atjola.homenet>
Björn Steinbrink <B.Steinbrink@gmx.de> writes:
Show 5 quoted lines
> Looking at --cached/--index we have basically three things: > > --cached to refer to the state of the index (diff, grep, [stash], ...) > --cached to _work on_ the index only (rm, apply, ...) > --index to _work on_ both the index and the working tree (apply, ...)
I think the earlier two are the same thing. The only difference between them is that in the first one, the definition of your "work on" happens to be a read-only operation. Am I mistaken?
> A quick look through Documentation/ revealed only one problematic case, > which is ls-files that already has a --stage option. And that looks like > a dealbreaker :-(
'ls-files' is primarily about the index contents and all else is a fluff ;-)
You could say --show-stage-too if you wanted to, but the command is a plumbing to begin with, so perhaps if we can identify the cases where people need to use the command and enhance some Porcelain (likely candidate is 'status' or perhaps 'status --short') to give the information people use ls-files for, we hopefully wouldn't have to change ls-files itself at all.
The only case I use ls-files these days when I am _using_ git (as opposed to developing/debugging git) is "git ls-files -u" to get the list of still unmerged paths during a conflicted merge.