On 08.03.13 09:15, Junio C Hamano wrote: > Torsten Bögershausen <tboegi@xxxxxx> writes: > >>> Doesn't this make one wonder why a separate bit and implementation >>> is necessary to say "I am not interested in untracked files" when >>> "-uno" option is already there? >> ... >> I need to admit that I wasn't aware about "git status -uno". > > Not so fast. I did not ask you "Why do you need a new one to solve > the same problem -uno already solves?" > >> Thinking about it, how many git users are aware of the speed penalty >> when running git status to find out which (tracked) files they had changed? >> >> Or to put it the other way, when a developer wants a quick overview >> about the files she changed, then git status -uno may be a good and fast friend. >> >> Does it make sence to stress put that someway in the documentation? >> >> diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt >> index 9f1ef9a..360d813 100644 >> --- a/Documentation/git-status.txt >> +++ b/Documentation/git-status.txt >> @@ -51,13 +51,18 @@ default is 'normal', i.e. show untracked files and directori >> + >> The possible options are: >> + >> - - 'no' - Show no untracked files >> + - 'no' - Show no untracked files (this is fastest) > > There is a trade-off around the use of -uno between safety and > performance. The default is not to use -uno so that you will not > forget to add a file you newly created (i.e safety). You would pay > for the safety with the cost to find such untracked files (i.e. > performance). > > I suspect that the documentation was written with the assumption > that at least for the people who are reading this part of the > documentation, the trade-off is obvious. In order to find more > information, you naturally need to spend more cycles. > > If the trade-off is not so obvious, however, I do not object at all > to describing it. But if we are to do so, I do object to mentioning > only one side of the trade-off. People who choose "fastest" needs > to be made very aware that they are disabling "safety". > > That brings us back to the "Why a separate implementation when -uno > is there?" question. [...] The short version: The -uno option does exactly what the -c option intended to do ;-) (The code path to disable the "expensive" call to read_directory_recursive() in dir.c is slightly different). Making benchmarks (again, sorry for the noise) shows that -uno and -c are equally fast, making 5 git status on a linux tree, take the best of 5: git status real 0m0.697s git status -uno real 0m0.291s (with the patch) git status -c real 0m0.289s These are not really scientific numbers, but all in all we have motivation enough to drop the "git status -c" patch completely. My feeling is still that the suggested documentation "this is fastest" is not a good choice either. Let me try to come up with a better suggestion. /Torsten -- 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