Yann Dirson wrote: > 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
