Hello I'm coming from cogito. There you can run: cg-add $file ; cg-rm $file and everything is as before; it adds the file to the directory index/cache, and just removes it again from the latter. Whereas with git, git-add $file; git-rm $file is giving the error error: '..file..' has changes staged in the index (hint: try -f) And sure enough, git rm -f $file will remove the file from the index, but also unlink it from the directory. (Ok, I did remember that cogito's -f option is unlinking the file, so I was cautious and didn't try it on an important file, but still...) Turns out that git rm -f --cached $file will do the same action as cg-rm $file. Why so complicated? Why not just make git-rm without options behave like cg-rm? (Or at the very least, I'd change the hint to say "try -f --cached".) Christian. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
| Greg KH | Og dreams of kernels |
| Jens Axboe | [PATCH 31/33] Fusion: sg chaining support |
| Arnd Bergmann | Re: finding your own dead "CONFIG_" variables |
| Mark Brown | [PATCH 2/2] Subject: natsemi: Allow users to disable workaround for DspCfg reset |
| Tony Breeds | [LGUEST] Look in object dir for .config |
git: | |
| Brian Downing | Re: Git in a Nutshell guide |
| John Benes | Re: master has some toys |
| Matthias Lederhofer | [PATCH 4/7] introduce GIT_WORK_TREE to specify the work tree |
| Alexander Sulfrian |
