Re: [PATCH v2] status: long status advice adapted to recent capabilities

[Rudy Rigot <rudy.rigot@gmail.com>]

Thanks a lot for all that feedback. Honestly you're way more familiar
than I am with both how the underlying features work, and how to best
contribute this change, so I'm comfortable taking your advice pretty
much blindly.


> Let me suggest an alternative commit message.  We want to lead with a
> "command" -- as in: "make Git do this" or "teach Git to do this".  Then
> explain why.

Oops, sorry for missing this. Well, your commit message suggestion
is flawless, I will reuse this as is. Thanks a lot for spending
time polishing it.


> I hate to suggest a complete rewrite
> [...]
> Something like that.  Hope this helps.  (And again, sorry for the
rewrite.)

There's absolutely nothing to apologize about. This is great! I
will also reuse as is. Here too, thanks a lot for the time spent
on this!


> small nit: we should have a final LF at the end of the file.

Sounds good, will fix.


> I'm going to skip over the test cases because I'm running
> short on time this afternoon.

That's all good, I need to align my submission to all this and
resubmit anyway, so you got time! I'm pretty confident about them
too, a lot more than in the phrasing of the user-facing content
I had.


> Also, we should refer to the documentation via `git help` rather
> than as a link to the website.

Oops, I didn't realize people were getting the same content from
either. I will fix.


> I'm not sure I like the various mixture of messages here.  Maybe
> it would be better with a single simple message:

That's the one thing I'm a bit concerned about, that I would like
to discuss more if that's ok.

The current confusion we're seeing with users of our very large repo,
is that they run git status the first time and notice it being slow
(~30s), and then they see the current advice message advising that
they're supposed to do something about it. What they don't know, is
that untrackedcache and fsmonitor were already set for their
environment, by the script setting their entire environment up.

I don't think it is unusual for users to not necessarily know how
their environment was configured (either because someone/something
else did it for them, or because they forgot what they did for
this specific repo, for instance).

So with that, I worry about the phrasing "See 'git help status' for
information on how to improve this." in that use case, because
it implies that there is something they are expected to go improve,
while that was already done.

Here are some solution ideas:

* Changing the wording for all use cases to not convey that they
must do anything about it. For instance just "See 'git help status'".
(I don't love this because I could imagine users being puzzled about
why Git is telling them this, then.)
* Informing the user of their current caching situation in ways
that they can deduce whether or not they should be doing something
about it. That's what I was attempting to do here, but reading your
help content, I think I got something wrong: I didn't realize the
cache would only need to warm up with untrackedcache + fsmonitor,
and not with untrackedcache alone. So with that an improvement could
be to only display "but this is currently being cached." when both
untrackedcache + fsmonitor are on, and not display anything different
when only untrackedcache is on then when it's not.
* Not displaying this advice message when fsmonitor is on, since
the best possible optimization was already applied. Not loving it,
because some could also still want untracked files off on top of it.
Also, it doesn't resolve the frustration of noticing git status being
slow the first time.

For now if you don't mind, I'll change things to the 2nd proposal up
there, but this is not because I'm rejecting your guidance and insisting
that adding a line here is the right solution to the situation of
environments that were already optimized, and I'm not sure what
is. But I do worry that telling those users that they should optimize
things while they/someone already did will surely be confusing.

I'll work on the other fixes, and I am deeply interested in your
thoughts about this one. Thanks a lot for working through this with
me.