Re: [PATCH] More permissive "git-rm --cached" behavior without -f.

From: Jeff King <peff@peff.net>
Date: Jul 13, 2007, 17:57 UTC
Message-ID: <20070713175737.GA20416@coredump.intra.peff.net>
In-Reply-To: <11843484982037-git-send-email-Matthieu.Moy@imag.fr>

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