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