Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > On Mon, 26 Mar 2007, Junio C Hamano wrote: > >> Jeff King <peff@xxxxxxxx> writes: >> >> > 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. - 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