Re: [RFC] git rm -u

From: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Date: Jan 20, 2013, 11:32 UTC
Message-ID: <vpq622s9jk1.fsf@grenoble-inp.fr>
In-Reply-To: <20130119214921.GE4009@elie.Belkin>

Jonathan Nieder <jrnieder@gmail.com> writes:

Show 9 quoted lines

> Eric James Michael Ritz wrote:
>
>> When I came to my senses and realized that does not work I began to
>> wonder if `git rm -u` should exist.  If any deleted, tracked files are
>> not part of the index to commit then `git rm -u` would add that change
>> to the index.
>
> I like it.  If you have time to write such a patch, I'll be happy to
> read it.

I can leave with "git add -u", but a "git rm -u" that would only look at deletions, and not stage existing files changes would make sense.

One thing to be careful about is what to do when the command is called from a subdirectory. In general, Git commands use this convention:

* git foo   => tree-wide command
* git foo . => restrict to current directory

"git add -u" is one of the only exceptions (with "git grep"). I consider this as a bug, and think this should be changed. This has been discussed several times here, but no one took the time to actually do the change (changing is easy, but having a correct migration plan wrt backward compatibility is not).

Implementing "git rm -u" as a tree-wide command would create a discrepancy with "git add -u". Implementing it as a "current directory" command would make the migration harder if we eventually try to change "git add -u". Perhaps "git rm -u" should be forbidden from a subdirectory (with an error message pointing to "git rm -u :/" and "git rm -u ."), waiting for a possible "git add -u" change.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/