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

From: Matthieu Moy <matthieu.moy@imag.fr>
Date: Jul 13, 2007, 18:53 UTC
Message-ID: <vpq8x9kp231.fsf@bauges.imag.fr>
In-Reply-To: <20070713175737.GA20416@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 8 quoted lines

> 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.

Show 7 quoted lines

> 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