Re: How to commit removed file?

[Carl Worth <cworth@cworth.org>]

[-- Attachment #1: Type: text/plain, Size: 2275 bytes --]

On Fri, 05 Jan 2007 17:57:16 -0800, Junio C Hamano wrote:
> Carl Worth <cworth@cworth.org> 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 #2: Type: application/pgp-signature, Size: 189 bytes --]