Re: [BUG] 'add -u' doesn't work from untracked subdir

From: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Date: Sep 6, 2009, 12:32 UTC
Message-ID: <vpqfxb0s177.fsf@bauges.imag.fr>
In-Reply-To: <20090905084641.GA24865@darc.dnsalias.org>

Clemens Buchacher <drizzd@aon.at> writes:

Show 17 quoted lines

> On Sat, Sep 05, 2009 at 12:02:35AM -0700, Junio C Hamano wrote:
>
>> I personally find "add -u" that defaults to the current directory more
>> natural than always going to the root; same preference for "grep".
>> Besides, "add -u subdir" must add subdir relative to the cwd, without
>> going to the root.  Why should "add -u" sans argument behave drastically
>> differently?
>
> Sorry for stating the obvious here, but the following commands affect the
> entire repository, even though they limit themselves to the current
> directory, if passed a '.'.
>
> 	git commit
> 	git log
> 	git diff
> 	git checkout
> 	git reset

You have to add "git add -e", "git add -i" and "git add -p" here.

I completely agree that "git add -u" should have been a full-tree oriented command, just like other "git add" variants and other Git commands, from the beginning.

Now, I'm unconfortable with both a behavior change and a config option. Someone used to the cwd-limited behavior typing "git add -u" on a machine configured to git the full-tree behavior could be really annoyed (not even mentionning scripts).

I think it has already been proposed to introduce "git add -a" doing what "git add -u" do, but for the full tree. The "-a" option here being analogous to the one of "git commit": roughly, "git add -a; git commit" would be equivalent to "git commit -a". This would allow a long deprecation period for "git add -u". I find the proposal sensible, but IIRC it has already been rejected.

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