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 -- 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