On Fri, 05 Jan 2007 17:57:16 -0800, Junio C Hamano wrote: > Carl Worth <cworth@xxxxxxxxxx> writes: > > On Tue, 02 Jan 2007 13:40:41 -0800, Junio C Hamano wrote: > >> Personally I never saw the point of having "git rm". Maybe we > >> should remove it to prevent this confusion from happening. > > > > The one place where it's really "necessary", (as opposed to some users > > just expecting it to be there), is to "undo" a git-add, (and I mean a > > git-add that actually adds a new path to the index, not one of these > > newfangled git-adds that simply updates content for an existing path). > > "git reset" (i.e. --mixed) is the way to revert the index back > to HEAD and start over. But that's a lot more than I want. Here's something like one of the original use cases that I hit and had in mind (as best I recall) that motivated be to write the initial git-rm command. It was something like adding a feature and a new test-case at the same time: git update-index src/Makefile git update-index src/some-feature.c git add test/feature-test.c # Hmm, wait, it'd be cleaner to add test/feature-test.c as a separate # commit. How can I undo that "git add" I just did? So, at this point, I could git-reset and start over, but I wanted a way to undo just the "add" and leave all the other updates still in the index. It's not really all that important to be able to undo the add, (there's not really a corresponding way to selectively undo the other update-index calls without using git-reset for everything). But now that I tried this case with a recent git (2a3a3c247) for which git-rm does working-tree removal without -f, I see that it does irretrievably destroy information in this case: $ echo "important stuff" > new-file $ git add new-file $ git rm new-file This now deletes new-file from the working tree and there's no copy of the data inside git. The old git-rm would just return the file to it's "untracked" state in this case. I had thought the safety check was going to be that the index state matched the HEAD state before git-rm would delete from the working tree. (Note, that I definitely agree that it's an improvement that git-rm does delete the working-tree file when the working-tree and index and HEAD all have the same content.) -Carl
Attachment:
pgpgAtg9Zni0O.pgp
Description: PGP signature