Linus Torvalds wrote: > I'd like it more if it defaulted to actually removing the file, preferably > refusing to with an error message if the file didn't match the index. index, or HEAD version? Otherwise you can "update-index"; "rm" without seeing something wrong is happening. > Final note: arguably, the current "git rm" is a better mirror image of > "git add" than what I suggest above. "git add" doesn't actually create the > working file (you had to do that yourself), so you _could_ argue that "git > rm" as it stands now is closer to the "reverse" of git add. The same is > true of the recursive behaviour. For this reason I think that the current behaviour is not so broken. Everywhere else, it is up to the user to make the changes to the working copy that they want to commit. I like git-rm because I can go: rm -rf whatever git-rm whatever I can see why you'd want git-rm -u whatever or rm -rf whatever git-commit -a An extra flag to actually unlink the files is less likely to cause bugs with porcelain expecting git-rm to behave as it does currently. If it is to be changed in backwards incompatible ways, there should probably be a deprecation time. "rm -u" could alter the default semantics, ie, require the extra -r option to recurse and require -f unless things are safe. Sam. - 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