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

From: Sam Vilain <sam@vilain.net>
Date: Dec 2, 2006, 20:00 UTC
Message-ID: <4571DB40.6020800@vilain.net>
In-Reply-To: <Pine.LNX.4.64.0612020919400.3476@woody.osdl.org>

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.

Show 5 quoted lines

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