Re: [PATCH] status: hint the user about -uno if read_directory takes too long

On Wed, Mar 13, 2013 at 10:21 PM, Torsten Bögershausen [off-list ref] wrote:

quoted

+     statusUno::
+             If collecting untracked files in linkgit:git-status[1]
+             takes more than 2 seconds, hint the user that the option
+             `-uno` could be used to stop collecting untracked files.

Thanks, I like the idea
could we make a "de-Luxe" version where

statusUno is an integer, counting in milliseconds?

No problem.

On Wed, Mar 13, 2013 at 11:16 PM, Junio C Hamano [off-list ref] wrote:

The noise this introduces to the test suite is a bit irritating and
makes us think twice if this really a good change.

I originally thought of two options, this or add an env flag in git
binary that turns this off in the test suite. The latter did not sound
good. But I forgot that we set a fake $HOME in the test suite, we
could disable this in $HOME/.gitconfig, less clutter in individual
tests.

quoted

 static void wt_status_print_unmerged(struct wt_status *s)
+             if (advice_status_uno && s->untracked_in_ms > 2000) {
+                     status_printf_ln(s, GIT_COLOR_NORMAL,
+                                      _("It took %.2f seconds to collect untracked files."),
+                                      (float)s->untracked_in_ms / 1000);
+                     status_printf_ln(s, GIT_COLOR_NORMAL,
+                                      _("If it happens often, you may want to use option -uno"));
+                     status_printf_ln(s, GIT_COLOR_NORMAL,
+                                      _("to speed up by stopping displaying untracked files"));
+             }

"to speed up by stopping displaying untracked files" does not look
like giving a balanced suggestion.  It is increasing the risk of
forgetting about newly created files the user may want to add, but
the risk is not properly warned.

How about "It took X ms to collect untracked files.\nCheck out the
option -u for a potential speedup"? I deliberately hide "no" so that
the user cannot blindly type and run it without reading document
first. We can give full explanation and warning there in the document.

I tend to agree that the new advice would help users if phrased in a
right way.  Do we want them in COLOR_NORMAL, or do we want to make
them stand out a bit more (do we have COLOR_BLINK ;-)?

There will be false positives (cold cache for example). So yeah
something more standing out is good but it should catch too much
attention. We're currently using red and green in status output. Maybe
this one can take blue.

PS. What about advertising index v4? I sent a patch some time ago to
put an advice in git-clone. I think it's a good place, but we could
place it somewhere else..
-- 
Duy