Junio C Hamano <gitster <at> pobox.com> writes: > > Matthieu Moy <Matthieu.Moy <at> imag.fr> writes: > > > Indeed, I've always considered the fact that "git status ." reports > > untracked files outside the current directory as a bug, but I'm not > > sure whether this is intended or not. > > It is intended. > > "git status $args" was designed as "show me what happens if I > ran 'git commit $args' now", and because a commit is a whole > tree operation, I am reopening/continuing this thread since, I also have an issue with this behaviour of git status. As I said in my report in the Debian BTS (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=471313) I do see the point (from a user PoV) of such a behavior of "git status ." . Of course, "git status" is another matter and is really OK to behave like is does, but "git status ." is only a duplicate of the former with no special meaning, while (I feel) most people would see it really pointless, undesired and unexpected to behave like it does now. I really think "git status ." should limit the search below the current dir, while "git status" should keep its current meaning. > It is a different matter if the intention matches the > expectation you picked up from somewhere on how "scm status" > should work (it most likely doesn't). It also is a different > matter if it is justifiable to have such a mismatch. I think it is justifiable, and I think is an improvement from a user (interface) PoV. TIA. [1] btw, git status --blabla shows what seems to be git-commit's help -- 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
