git-ls-files handling of 'missing' files

git-ls-files appears to treat missing files as both removed /and/ modified, neither of which really seems right. Perhaps a new state, 'missing', is worthwhile?

Also, the documentation for git-ls-files is a bit confusing to me:

(aside: I assume that the '?' is a mis-typed '/')

The documentation confuses me when it says that files marked with a 'K' are "to be killed / other" - it don't understand why 'killed' and 'other' are lumped together.

The docs for git-ls-files indicate that a file marked as 'killed' (wrong tense?) is a file that needs to be removed for git-checkout-index to succeed. The manpage doesn't say why git-checkout-index needs to succeed or under what conditions git-checkout-index would be invoked. (ie, "why" should I manually remove this file).

Would it also be worthwhile to change the terminology used? Specifically, it seems that 'unchanged' is more readily understandable than 'cached', and the past tense of 'killed' throws me. I can offer no improvement there, however.

It seems to me that files can also exist in the state 'new' or 'added' (is this the same as unmerged?) Is there a state for 'conflict'?

Sorry for all of the questions, I've really been enjoying using git but every now and again something thows me - tonight it was git-ls-files. ;-)

-- Jon Nelson <jnelson-git@jamponi.net>