From: Junio C Hamano Date: Tue, 03 Jul 2007 05:09:35 GMT Subject: Re: git-rm isn't the inverse action of git-add Message-ID: <7v4pkmt6nk.fsf@assigned-by-dhcp.cox.net> In-Reply-To: <20070703045948.GE4007@coredump.intra.peff.net> Jeff King writes: > OTOH, clearly git-add can "lose" data in this way as well, since a > "modify, git-add, modify, git-add" will "lose" any reference to the > index state after the first add. So maybe that is not worth worrying > about at all (in which case our safety valve is too strict in many > places). Exactly. And not considering that lossage helps us keep our sanity. I think "git rm --cached" falls into the same category. If the user wants to discard what is in the index without losing a copy in the working tree, I think we should let him do without fuss. > git-add foo > echo changes >>foo > # oops, I don't want to commit foo just yet > git-rm --cached foo > > but in that case, maybe the user doesn't actually _care_ about that > intermediate state of 'foo'. Yes, that is (at least, "used to be") exactly the use case "rm --cached" is supposed to help. Added something prematurely to the index, not ready to commit that part of the changes yet. Of course you could do partial commits with "add --interactive" these days, so there is not as much need for this as it used to be anymore.