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

From: Matthieu Moy <matthieu.moy@imag.fr>
Date: Jul 14, 2007, 10:14 UTC
Message-ID: <vpqy7hjl2c3.fsf@bauges.imag.fr>
In-Reply-To: <7vy7hjjw01.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano <gitster@pobox.com> writes:

Show 22 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
>
>> Although I would not be using it often myself, I think this
>> would make "git rm" more pleasant to use.
>>
>> Thanks for the patch, and my thanks also go to people who
>> commented on the patch.
>
> Having said that, I think this comment is not quite right.
>
> +		else if (!index_only) {
> +			/* It's not dangerous to git-rm --cached a
> +			 * file if the index matches the file or the
> +			 * HEAD, since it means the deleted content is
> +			 * still available somewhere.
> +			 */
>
> Personally I do not think "rm --cached" needs any such "safety",
> even though I'll keep the check for now, primarily because
> loosening the restriction later is always easier than adding new
> restriction.  I really do not think this is about protecting the
> user from "deleted content is not available anywhere else".

I agree that this is something you can argue about.

But in this case, the behavior without -f should be changed too. If the file matches HEAD, then "git-rm file" should work, regardless of the index then (but this situation is less frequent).

In any case, the situation where you might lose content in the index by doing git-rm are rare: it means you started working on a file, did "git-add" at least once, and edited the file again later, and then decided you wanted to remove the file. So, requiring the -f flag in those situation is not a real problem, even if the situation is slightly-dangerous-but-not-quite-so.

I'm willing to work on another patch on top of this one if there's an agreement on a better semantics. This one was about fixing something which was IMHO wrong, but doesn't necessarily achieve perfection ;-).

-- 
Matthieu