Re: git-rm isn't the inverse action of git-add

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 3, 2007, 05:09 UTC
Message-ID: <7v4pkmt6nk.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20070703045948.GE4007@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 5 quoted lines

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

Show 7 quoted lines

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