Jonathan Nieder <jrnie...@gmail.com> writes:

> 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/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to