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