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

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 14, 2007, 07:16 UTC
Message-ID: <7vy7hjjw01.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <7vfy3rlbnp.fsf@assigned-by-dhcp.cox.net>

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

Show 5 quoted lines

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

In this sequence:

	edit a-new-file
	git add a-new-file
        edit a-new-file
        git add a-new-file

we do not complain, even though we are *losing* the contents we earlier staged. If you replace the second "git add" with "git-rm --cached", the sequence should work the same way. In either case, you are working towards your next commit, and most likely are doing a partial commit (iow, your working tree does not match any of the commit you create in the middle). Earlier you thought you would want one state of the file in the next commit, but now you decided against putting that new file in the first commit in the series. You may make further updates to the index and would make a commit, but after making the commit, your working tree still has "a-new-file" and you can add the contents from it for the later commit.