On 10/22/2018 8:23 PM, Junio C Hamano wrote:
Ben Peart <peart...@gmail.com> writes:
From: Ben Peart <benpe...@microsoft.com>
refresh_index() is done after a reset command as an optimization. Because
it can be an expensive call, warn the user if it takes more than 2 seconds
and tell them how to avoid it using the --quiet command line option or
reset.quiet config setting.
I am moderately negative on this step. It will irritate users who
know about and still choose not to use the "--quiet" option, because
they want to gain performance in later real work and/or they want to
know what paths are now dirty. A working tree that needs long time
to refresh will take long time to instead do "cached stat info says
it may be modified so let's run 'diff' for real---we may discover
that there wasn't any change after all" when a "git diff" is run
after a "reset --quiet" that does not refresh; i.e. there would be
valid reasons to run "reset" without "--quiet".
It feels a bit irresponsible to throw an ad without informing
pros-and-cons and to pretend that we are advising on BCP. In
general, we do *not* advertise new features randomly like this.
Thanks. The previous two steps looks quite sensible.
The challenge I'm trying to address is the discoverability of this
significant performance win. In earlier review feedback, all mention of
this option speeding up reset was removed. I added this patch to enable
users to find out it even exists as an option.
While I modeled this on the untracked files/--uno and ahead/behind
logic, I missed adding this to the 'advice' logic so that it can be
turned off and avoid irritating users. I'll send an updated patch that
corrects that.
