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

From: Clemens Buchacher <[email-masked]>
Date: Mon, 7 Sep 2009 09:50:58 +0200

On Mon, Sep 07, 2009 at 09:07:13AM +0900, Nanako Shiraishi wrote:

> The default behavior for 'git-grep' has already been discussed in length,
> and I don't think it is likely to change. See 
> 
>   http://thread.gmane.org/gmane.comp.version-control.git/111519/focus=111717

Actually, most responded with the request for a command or config option,
and did not refuse the idea outright. One was not even aware that this is
how "git grep" behaves. And neither was I until a few days ago.

And that is kind of dangerous with this command. You expect it to behave
analogously to other git commands, but it doesn't. And because grep simply
does not search superdirectories, you may think that there are in fact no
matches so you don't even notice that behavior!

> I think it is a good idea to fix this as an old regression in the maint
> branch. You don't have to introduce "git add -a". In fact the -a option
> was explicitly rejected when "git add -A" option was added with this
> commit. 
> 
>   3ba1f11 "git-add --all: add all files"
> 
> because "git commit -a" will never include new files and it will be inconsistent if "git add -a" did so.

I certainly don't mind fixing "git add -u". But I was not suggesting "git
add -a" instead of "git add -A". The idea was to introduce it instead of
"git add -u" (which can be deprecated later), so that the following are
exactly the same.

	"git add -a; git commit"
	"git commit -a"

That way, scripts are not silently broken.

OTOH, "git add --all" is already inconsistent with "git commit --all". And
we would still need a new command for 'global' "add -A". *sigh*

Clemens