From: Ben Peart Date: Tue, 23 Oct 2018 17:12:53 GMT Subject: Re: [PATCH v3 3/3] reset: warn when refresh_index() takes more than 2 seconds Message-ID: <50195f7a-c452-c784-ab23-d05956d48470@gmail.com> In-Reply-To: On 10/22/2018 8:23 PM, Junio C Hamano wrote: > Ben Peart writes: > >> From: Ben Peart >> >> 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.