Jeff King <peff@xxxxxxxx> writes: > On Fri, Jul 13, 2007 at 07:41:38PM +0200, Matthieu Moy wrote: > >> Previously, the index had to match the file *and* the HEAD. With >> --cached, the index must now match the file *or* the HEAD. The behavior >> without --cached is unchanged, but provides better error messages. > > This does make more sense, but there are still some inconsistencies. Is > it OK to lose content that is only in the index, or not? I'd say it isn't OK. At least, that's what the previous git-rm considered. > If it is OK, then --cached shouldn't need _any_ safety valve (and after > all, anything you remove in that manner is recoverable with git-fsck > until the next prune). > > If it isn't OK, then you are not addressing the cases where git-rm > without --cached loses index content (that is different than HEAD and > the working tree). Either I didn't understand your question, or the answer is "yes, I do.". The behavior without --cached is not modified, except for the error message, and the previous was to require -f whenever the index doesn't match the head, *or* doesn't match the file. So, without --cached, you need to have file=index=HEAD to be able to git-rm. If I missunderstand you, please, provide a senario where my patch doesn't do the expected. -- Matthieu - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
