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

Junio C Hamano [off-list ref] writes:

Clemens Buchacher [off-list ref] writes:

quoted

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

Limit the scope of what you see in "ls" (no argument) output, shorten the
paths you must type to non-git commands.  They are the kind of "limit the
scope" I meant, and they are totally versioning-unrelated.  In other
words, cwd-centric default helps the users (especially the new ones) by
making git behave consistently with other commands.

Well, there is still complication that some commands are considered
whole-tree in absence of pathspec, like "git commit".

So if anything, I personally think it would be much less surprising if all
git commands worked relative to the cwd (not whole tree root) when run
without path argument, at least from the newbie's point of view [*1*].

I think it would be very suprising if "git commit" in subdirectory was
limited to changes affecting given subdirectory...

But notice that the above is qualified with "personally".  An alternative
would be to declare that in 1.8.0, all commands run without path argument
will work on the whole tree and you have to give an explicit '.' when you
want to limit their effect to the cwd.

This may be slightly less intuitive to newbies than the "relative to cwd",
but nevertheless that is the course I would suggest us taking, because of
the following observations:

 (1) if the commands work on the whole tree when run without paths, it is
     easy to limit to the cwd with "git frotz ." when you want to.

 (2) if the commands work on the cwd when run without paths, you have to
     always be aware how deep you are, and say "git frotz ../../.." when
     you want to extend their effects to the whole tree.

The latter is much more irritating.

Well, we can always invent some magic notation meaning either "up to
top directory", e.g. make

  $ git frotz ...

more or less equivalent to

  $ git frotz "$(git rev-parse --show-cdup)"

(The other solution of having "git frotz /" to refer to top directory
is slightly worse, because there are git commands that work without
git repository, and "/" is legitimate parameter, like e.g. for 
"git diff --no-index").

-- 
Jakub Narebski
Poland
ShadeHawk on #git