On Wed, Oct 17, 2018 at 02:14:32PM -0400, Eric Sunshine wrote: > > diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt > > @@ -95,7 +95,9 @@ OPTIONS > > --quiet:: > > - Be quiet, only report errors. > > + Be quiet, only report errors. Can optimize the performance of reset > > + by avoiding scaning all files in the repo looking for additional > > + unstaged changes. > > s/scaning/scanning/ > > However, I'm not convinced that this should be documented here or at > least in this fashion. When I read this new documentation before > reading the commit message, I was baffled by what it was trying to say > since --quiet'ness is a superficial quality, not an optimizer. My > knee-jerk reaction is that it doesn't belong in end-user documentation > at all since it's an implementation detail, however, I can see that > such knowledge could be handy for people in situations which would be > helped by this. That said, if you do document it, this doesn't feel > like the correct place to do so; it should be in a "Discussion" > section or something. (Who would expect to find --quiet documentation > talking about optimizations? Likely, nobody.)
Yeah, I had the same thought. You'd probably choose --quiet because you want it, you know, quiet. Whereas for the new config variable, you'd probably set it not because you want it quiet all the time, but because you want to get some time savings. So there it does make sense to me to explain. Other than that, this seems like an obvious and easy win. It does feel a little hacky (you're really losing something in the output, and ideally we'd just be able to give that answer quickly), but this may be OK as a hack in the interim. The sad thing is just that it's user-facing, so we have to respect it forever. I almost wonder if there should be a global core.optimizeMessages or something that tries to tradeoff less information for speed in all commands, but makes no promises about which. Then a user with a big repo who sets it once will get the benefit as more areas are identified (I think "status" already has a similar case with ahead/behind)? And vice versa, as some messages get faster to produce, they can be dropped from that option. I dunno. Maybe that is a stupid idea, and people really do want to control it on a per-message basis. -Peff
