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

Johannes Schindelin [off-list ref] writes:

On Mon, 26 Mar 2007, Junio C Hamano wrote:

quoted

Jeff King [off-list ref] writes:

quoted

Given this set of commands:

  $ echo "newly added file" >new
  $ git add new
  $ git rm new

the file "new" was previously removed from the working
directory and the index. Because it was not in HEAD, it is
available only by searching for unreachable objects.

I am not sure if this is a problem, as the user asked it to be
removed.  It somehow feels to me that the change (I am not
convinced your patch should be called a "fix" rather than a
"behaviour change") would cause more confusion.

I agree it would add to confusion.

It is well established that "git rm" also removes the file _in the working 
directory_.

If you don't want the file to be deleted, but only the corresponding 
entry _in the index_, use "git rm --cached".

Actually, thinking about it a bit more, I think Jeff's patch is
in line with the current behaviour.

Looking at the cases where we prevent 'git rm' without '-f'
succeeding currently, the motivation is to save the user from
mistakenly saying "remove" when the user earlier said "this
change matters in the next commit" to us.

For example, with "edit existing-file; git add existing-file",
the user said the new state of the file matters in the next
commit.  And we refuse to remove, saying "foo has changes
staged".

By saying "edit new-file; git add new-file", the user expressed
the intent to add that content to the upcoming commit.  Saying
"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
given for existing files that has staged changes, saying "you
earlier said you want changes to this file in the next commit.
are you sure you have changed your mind?"

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.