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

[Sam Vilain <sam@vilain.net>]

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.