Re: [PATCH] git-rm: don't remove newly added file without -f

On Mon, Mar 26, 2007 at 02:11:42PM -0700, Junio C Hamano wrote:

Unstaging request would have looked like "git reset HEAD new",
wouldn't it?

Yes, I think I am still in the habit of using "git rm" from its old
usage. I unstage so rarely that I don't think my fingers have adjusted.

"git rm" later is reverting that intent.  Jeff's patch does
exactly the same thing for new files what we already do for
existing ones --- we ask for a confirmation when "git rm" is

Yes, regardless of how git-rm is "supposed" to be used, I think this
patch is worth it for two reasons:
  1. consistency; we should treat newly added files just like existing
     files (after all, content is content, right?)
  2. safety; I work under the assumption that I can do whatever I want
     with git-rm, and it will _never_ lose my data unless I use -f.
     Granted, without this patch my data would still be available
     somewhere in the object database, but it is hard to find and
     susceptible to pruning.

Having said that, we do _not_ ask for confirmation when you do
"git add existing-file" after doing "edit ; git add", which is
theoretically inconsistent, but rm is special so that is
probably Ok.

Hmm, yes, I agree that is inconsistent. However, it's such a common
workflow that forcing a '-f' would become meaningless. And you _can_
rescue the blob from the object database in a pinch, though finding it
can be tedious.

-Peff