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

[Nanako Shiraishi <nanako3@lavabit.com>]

Quoting Clemens Buchacher <drizzd@aon.at>

> 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
>
> Due to the frequent use of these commands, I believe many users (myself
> included) expect "git add" and "git grep" to do the same. AFAICT the
> following commands are the only non-plumbing ones that behave differently:
>
> 	git add -u
> 	git add -A
> 	git grep
>
> So I argue that _that_ is the real inconsistency.

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

The original design for the other two in your list was to be a whole tree operation. This commit broke it. 

  2ed2c22 "git-add -u paths... now works from subdirectory".

'git-add -u' in a subdirectory without any other argument used to work on the entire working tree before that commit, but it didn't prefix the current directory in front of the paths... arguments. 

That commit 2ed2c22 fixed 'git-add -u paths...' by prepending the prefix to the arguments, but it broke 'git-add -u' to always limit the updates to the current directory. 

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.

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/