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

From: Jeff King <peff@peff.net>
Date: Mar 26, 2007, 22:22 UTC
Message-ID: <20070326222239.GA3498@coredump.intra.peff.net>
In-Reply-To: <7vslbrvgf1.fsf@assigned-by-dhcp.cox.net>

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