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
