Re: [PATCH v1 1/2] reset: don't compute unstaged changes after reset when --quiet

[Jeff King <peff@peff.net>]

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