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

[Clemens Buchacher <drizzd@aon.at>]

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

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.

> If "git add -u ../.." (I mean "the grand parent directory", not "an
> unnamed subdirectory") did not work, it would be unexcusable and we would
> want to devise an migration path, but otherwise I do not think it is such
> a big deal.

> I would say the commands that are used to incrementally build
> towards the next commit should be friendly to the practice of limiting the
> scope of the work by chdir.

"git add -u ." is friendly enough. Just like "git commit ." versus "git
commit -a", which is exactly the same concept and should therefore have the
same behavior.

You are assuming that people are in a subdirectory because they want to
limit the scope. But I am usually in a subdirectory for totally
versioning-unrelated reasons. Like running tests in git.git:t/ . I
mistakenly use "git add -u" in there all the time, because I think I don't
have to worry about which directory I'm in. Except in this instance I do.

In any case, I think it is better to have consistent behavior than to try
and read users' minds with defaults.

Clemens