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

From: Yann Dirson <ydirson@altern.org>
Date: Jul 2, 2007, 20:40 UTC
Message-ID: <20070702204051.GP7730@nan92-1-81-57-214-146.fbx.proxad.net>
In-Reply-To: <46895EA4.5040803@jaeger.mine.nu>

On Mon, Jul 02, 2007 at 10:23:00PM +0200, Christian Jaeger wrote:

> I don't per se require undo actions. I just don't understand why git-rm
> refuses to remove the file from the index, even if I didn't commit it.

I'd say it does so, so you won't loose any uncommitted changes without knowing it - and "git add -f" is available when you have checked that you indeed want to discard that data.

Show 5 quoted lines

> The index is just an intermediate record of the changes in my
> understandings, and the rm action would also be intermediate until it's
> being committed. And a non-committed action being deleted shouldn't need
> a special confirmation from me, especially not one which is consisting
> of a combination of two flags (of which one is a destructive one).

It already works as such: it will warn you if you have already staged the file in the index, but it has not been committed, in which case the data would be lost as well:

$ echo foo > bar /tmp/test$ git rm bar fatal: pathspec 'bar' did not match any files /tmp/test$ git add bar /tmp/test$ git rm bar error: 'bar' has changes staged in the index (hint: try -f)

That is, "git rm" will only ever remove the file without asking, when it is safe do so, in that you can retrieve your file from history. Or do you think of another way, in which more safety would be needed ?

Best regards,

-- 
Yann