Torsten Bögershausen <tbo...@web.de> 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. Your patch adds new code; it does not just enables the same logic as what the existing -uno does with a new flag. Does the new compute different things? Does it find more stuff by spending extra cycles? Does it find less stuff by being extra faster? These questions are important. If the new option strikes the trade-off between safety and performance at a point different from the point where the existing -uno option does, it _might_ still be worth adding as a separate option. I didn't get that impression when I saw the patch, but I admit that I did not follow the code carefully myself. That is the reason why I was wondering why a separate bit and implementation had to be added by the patch. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html