Junio C Hamano <gitster@xxxxxxxxx> writes: > Clemens Buchacher <drizzd@xxxxxx> writes: > > > "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 -- 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