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

From: Christian Jaeger <christian@jaeger.mine.nu>
Date: Jul 2, 2007, 21:20 UTC
Message-ID: <46896C3B.1050406@jaeger.mine.nu>
In-Reply-To: <20070702204051.GP7730@nan92-1-81-57-214-146.fbx.proxad.net>

Yann Dirson wrote:

Show 10 quoted lines

> 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.
>

I'm really realising that

git-rm $file # where $file *has* been committed previously

does remove *and* unlink the file. (cg-rm does unlink only with the -f flag, as said.)

So there's no -f flag in normal git-rm usage. It thus has a different meaning, namely "force the operation pair of removing from index and unlinking", not "force this operation also onto the checked out files" as is the case with cogito.

So I now understand better why they invented the -f flag to git-rm for the case you're mentioning above and why the hint doesn't warn about it's danger, since git-rm is always dangerous. (Ok, as is "rm" without the "-i"; I just found it normal that cogito behaved like my "-i" setup.)

Regarding the issue of "lost files" because they have been created, added, and removed again before committing: as far as I remember this has never happened to me with cogito. I commit often, so if I add a file or a few, in most cases I commit just this fact (that they have been added), before doing more fancy stuff. I'm maybe used to thinking in database terms, work that isn't committed is lost. So if I create a file and add it, in my brain the "attention, uncommitted work" flag is on, and it usually doesn't happen that I later erroneously think the work has been committed when in fact it isn't. (I can always check with a quick cg-status (which shows the files as "A", which makes them stand out better than in the git-status output)).

Just before writing this mail I had a case where I wanted to remove a file from versioning control, but keep it on disk (I used git-rm and that's how I learned that it really also unlinks the local file without asking(*)). Note that this has not been an undo action; the file has been committed previously.

(* thanks to git-reset I could get it back of course)

>
> 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.

(Well it's not safe if you want to remove the file *from the index* and naively mis-use the -f flag as suggested by the hint.)

>  Or
> do you think of another way, in which more safety would be needed ?
>

I think we have just two different points in our view where we think safety matters.

Regarding the man pages: yes the git-rm man page is fine, and it's nice to see the manuals are improving. As noted I came from cogito, and didn't expect git to behave so different with the same named (but different purpose) options, so I didn't read the man pages (I've been in irc and asked there, where someone suggested to bring this to the list; I'm too tired today to think further about it and will try to read more docs and hope I'll get to understand the git philosophies more).

Christian.