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

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

> One thing that I find glaringly omitted, which since you're working on
> this you might consider adding: Suggest to just try running the exact
> same command again, maybe it was just the FS cache.

I have to admit that would be by far my personal preference.


We've been having a number of very great points made by several people
on this thread, but a number of them contradicting each other across
people, and yet clearly nobody's wrong, everybody makes very real
points. I'm trying to turn this into actionable changes I should make,
but I think I need guidance on that. This is my first ever contribution
to the project, so I'm lacking the organizational awareness of the
project to be able to drive this to a consensus on what we should do.

Here's a proposal that tries to make opinionated moves towards what
I understand to be the priorities that were expressed:


1- We keep the new paragraph doc, because I'd say why not, it's
well-written (thanks Jeff!) and useful. When people are looking for
ways to make git status faster, it's good that there's a reference
about it, and I'd expect it to be a common need across all kinds
of user situations.


2- When untracked cache is not on, if I understand Ævar's suggestion,
it would say something like:

> It took %.2f seconds to enumerate untracked files.
> Try to enable untracked cache to see if it helps make it faster
> for you:
>    git config core.untrackedCache true

It would satisfy that the message gives concise advice with actionable
next steps, without making assumptions about whether it will or won't
work. (Untracked cache alone did not make much of a difference in our
very large repo's case.) And it doesn't point to the help anymore, in
order not to saturate the user with too much detail.


3- When untrackedcache is on but fsmonitor is off, and git status is
still slow (that's the situation we had on our very large repo), it
could say something like:

> It took %.2f seconds to enumerate untracked files.
> Try to enable FSMonitor to see if it helps make it faster for you:
>    git config core.fsmonitor true

Same as before, concise, no assumptions.

This setup is more advanced, but we are in a case where untracked cache
is not helping, so I'm thining that should be very few repos.
If the user feels a need to better understand what's up, the feature
is mentioned by name, so they can look it up and dig in if they wish to.


4- When fsmonitor is on:

> It took %.2f seconds to enumerate untracked files.
> Your runs are being cached, try running git status again to see if
> it's faster.

Same as before, concise, no assumptions, and matches Ævar's suggestion
above that was also my preference, as it would apply perfectly to our
very large repo's use case and the grievances we've received.


Please let me know what your thoughts are about it all. A downside with
all that is the option to disable untracked files is not mentioned at
all, but if we keep the doc as it is, and it gets painful enough that
they search for other ways, I'm hopefuly the user would find it there.


I want to say it again: I'm not very opinionated about any of this,
just trying to collate feedback into an actionable plan. If I understood
feedback wrong, or my plan is not the best based on the feedback, that
is very fine, but I will need guidance to know what makes more sense.


> the untracked cache is
> pretty much an unambiguous win (we should probably turn it on on
> default, but we'd need to check on-the-fly if the FS supports it
> properly).

I could take on the work to make untracked cache on by default after
this, as another patch, if it sounds relevant to try. I feel I
lack the technical understanding of what we need to check that you're
mentioning here, so I'll have questions, but I'd be on board with
trying.