Re: On removing files and "git-rm is pointless"

Nicolas Pitre [off-list ref] writes:

I think what Linus is proposing makes tons of sense.

If you do git rm by mistake then you can always do git checkout on that
file to get it back.

If you modified it so it doesn't match the index then git rm won't do
anything by default so you have a chance to think a bit more.

If you updated the index, didn't commit anything but then do git rm then
you certainly wanted to really rm the file.

FWIW, I too am in favor of the proposed fix to "git rm" as Linus
outlined.

<pet_peeve>

On Mon, Dec 04, 2006 at 07:42:26AM -0800, Linus Torvalds wrote:

(And obviously, for all the normal reasons, if the index or HEAD doesn't 
match, the error message should be helpful and also explicitly mention the 
"-f" flag. Somehing like

	file 'x' does not match HEAD or has been staged for changes.
	Will not remove. Use '-f' to force removal.

And you wouldn't tell which, you stupid computer?

I hate when error messages go "there is a problem that may be x, y or
z.  You can figure out which one yourself.".

Incidentally, splitting the message would allow you to add a "use git
diff x" or a "use git diff --cached x to see the differences" message.

</pet_peeve>

On Mon, 04 Dec 2006 22:29:13 -0500 (EST), Nicolas Pitre wrote:

On Mon, 4 Dec 2006, Junio C Hamano wrote:

quoted

Hmph.  Wouldn't this lossage the same as the lossage we are
removing the "safety valve" for, when "commit --only" jumps the
index?

Losing an intermediate file state is much less severe than losing the
latest file state I would think.

Or, in fact, the _only_ state, (if using git-rm to "undo" a git-add of
a new file, for instance).

And as for "jumping" the intermediate state without the safety valve
of "git commit files..." I'm waiting to hear what Junio has to say
about my "two conceptually distinct commit commands" proposal which
would provide a way to avoid that, (the user just indicates whether
it's index content or working-tree content that is to be committed).

-Carl

Linus Torvalds [off-list ref] writes:

If it doesn't match HEAD, we can't get it back as easily, so maybe that's 
the case when we want to have "git rm -f filename".

Hmph.  Wouldn't this lossage the same as the lossage we are
removing the "safety valve" for, when "commit --only" jumps the
index?

On Mon, 4 Dec 2006, Junio C Hamano wrote:

FWIW, I too am in favor of the proposed fix to "git rm" as Linus
outlined.

Note that somebody (sorry, forget who) correctly pointed out that in order 
to be "safe", the file that you "rm" has to match not only the index, but 
it should match the HEAD tree too.

If it matches both the index and the HEAD tree, a "git rm filename" is 
totally safe, since you can always get it back by just doing a

	git checkout HEAD filename

so the "git rm" really didn't lose any info, and as such, we can _happily_ 
remove the working tree copy without any concern at all.

If it doesn't match HEAD, we can't get it back as easily, so maybe that's 
the case when we want to have "git rm -f filename".

(And obviously, for all the normal reasons, if the index or HEAD doesn't 
match, the error message should be helpful and also explicitly mention the 
"-f" flag. Somehing like

	file 'x' does not match HEAD or has been staged for changes.
	Will not remove. Use '-f' to force removal.

("has been staged for changes" is just a long way of saying "index". See? 
I _can_ learn.)

Linus Torvalds wrote:

(And obviously, for all the normal reasons, if the index or HEAD doesn't 
match, the error message should be helpful and also explicitly mention the 
"-f" flag. Somehing like

        file 'x' does not match HEAD or has been staged for changes.
        Will not remove. Use '-f' to force removal.

("has been staged for changes" is just a long way of saying "index". See? 
I _can_ learn.)

I'd rather have

        File 'x' does not match HEAD or index (has been staged for changes).
        Will not remove. Use "git rm -f 'x'" to force removal.

I'd rather not learn that "staged for changes" mean "index". I'm quote
comfortable with the concept of "index" and the name "index",
thankyouverymuch.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Junio C Hamano wrote:

Nicolas Pitre [off-list ref] writes:

quoted

I think what Linus is proposing makes tons of sense.

If you do git rm by mistake then you can always do git checkout on that
file to get it back.

If you modified it so it doesn't match the index then git rm won't do
anything by default so you have a chance to think a bit more.

If you updated the index, didn't commit anything but then do git rm then
you certainly wanted to really rm the file.

FWIW, I too am in favor of the proposed fix to "git rm" as Linus
outlined.

+1. I'm also for this change. Of course if the working area version doesn't
match HEAD version git-rm should remove only index entry, and print warning
message, for example what it does now, i.e.
  rm '<filename>'
or if we want more chatty version (core.gitgor = true) it would print:
  File '<filename>' changed. Use "rm '<filename>'" to remove.
(or something like that).

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

On Mon, 4 Dec 2006, Junio C Hamano wrote:

Linus Torvalds [off-list ref] writes:

quoted

If it doesn't match HEAD, we can't get it back as easily, so maybe that's 
the case when we want to have "git rm -f filename".

Hmph.  Wouldn't this lossage the same as the lossage we are
removing the "safety valve" for, when "commit --only" jumps the
index?

Losing an intermediate file state is much less severe than losing the 
latest file state I would think.