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? 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). -Peff - 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
