From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Rudy Rigot <rudy.rigot@gmail.com>
Cc: Taylor Blau <me@ttaylorr.com>,
Jeff Hostetler <git@jeffhostetler.com>,
Rudy Rigot via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org
Subject: Re: [PATCH v2] status: long status advice adapted to recent capabilities
Date: Fri, 04 Nov 2022 09:52:59 +0100 [thread overview]
Message-ID: <221104.867d0byu5e.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <CANaDLWK6-KkfKP0mipuWccfQFacDWsLHFNjS7ogL_xWvvmrCfQ@mail.gmail.com>
On Thu, Nov 03 2022, Rudy Rigot wrote:
>> looking up an unknown configuration variable with 'man
>> git-config' is easy enough.
>
> I'm not strongly opinionated, but I believe the initial idea behind
> redirecting them to the doc was because Git now comes with more
> configuration abilities to improve performance of git status, that may
> be more or less relevant depending on use cases, so there
> isn't really a single git-config key for them to look up any more. Their
> ideal solution could be core.untrackedCache=true, core.fsmonitor=true,
> advice.statusUoption=false, status.showUntrackedFiles=false, or even
> some combinations of those can be relevant.
>
> From there, the goal I believe we were going for with this new doc
> section is to let users know what configs exist for their git status
> slowness pains and why, so they can then go look those configs up for
> more details, which I agree would indeed be easy from there.
>
> Again, I'm not strongly opinionated, and I hope I accurately represented
> the inital thinking on this idea.
>
> One slightly stronger opinion I have, is that if the advice message
> was just
>
>> It took %.2f seconds to enumerate untracked files.
>
> and nothing else, I can definitely see a strong UX downside of not
> giving a hint of next steps for users. Basically, "you have a problem,
> and we're not helping you resolve it". Were you thinking more of
> something like this?
>
>> It took %.2f seconds to enumerate untracked files.
>> Please look up the core.untrackedCache, core.fsmonitor
>> advice.statusUoption, and status.showUntrackedFiles configs
>> for potential solutions.
>
> I'd say that's probably somewhat cryptic and a bit verbose (which is
> what we were trying to avoid by telling them to go see the doc), but
> we wouldn't be leaving the user stranded, so I can see how that would
> work out ok.
>
> I'm very interested in what you think.
On the topic in general: I think it's probably a good thing to show the
advice, but I just want to point out that it's not without cost.
Right now we're showing users a pretty basic command they can try, but
now we're showing them other stuff that needs more complex setup.
For some they're probably way better off, e.g. 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).
But for e.g. fsmonitor the user may spend a lot of time fiddling with
it, only to find it doesn't help their use-case much, if it all.
Should we still point out these possibilities? Probably, but just say'n.
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.e. we're suggesting all this advanced stuff, but by far the biggest
difference is made on e.g. a modern *nix box (particularly Linux) by
just having all the repo's assets in the FS cache.
next prev parent reply other threads:[~2022-11-04 8:57 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-15 13:04 [PATCH] fsmonitor: long status advice adapted to the fsmonitor use case Rudy Rigot via GitGitGadget
2022-10-15 13:08 ` Rudy Rigot
2022-10-17 15:39 ` Jeff Hostetler
2022-10-17 16:59 ` Rudy Rigot
2022-10-20 12:56 ` Jeff Hostetler
2022-10-20 20:17 ` Rudy Rigot
2022-10-24 14:55 ` Jeff Hostetler
2022-10-29 0:06 ` [PATCH v2] status: long status advice adapted to recent capabilities Rudy Rigot via GitGitGadget
2022-11-02 19:45 ` Jeff Hostetler
2022-11-02 20:34 ` Rudy Rigot
2022-11-02 23:59 ` Taylor Blau
2022-11-03 14:28 ` Rudy Rigot
2022-11-04 8:52 ` Ævar Arnfjörð Bjarmason [this message]
2022-11-04 15:33 ` Rudy Rigot
2022-11-04 21:38 ` Taylor Blau
2022-11-02 21:27 ` [PATCH v3] " Rudy Rigot via GitGitGadget
2022-11-04 21:40 ` Taylor Blau
2022-11-07 20:02 ` Derrick Stolee
2022-11-07 23:19 ` Taylor Blau
2022-11-15 16:38 ` Jeff Hostetler
2022-11-07 20:01 ` Derrick Stolee
2022-11-07 20:20 ` Eric Sunshine
2022-11-07 20:31 ` Rudy Rigot
2022-11-10 4:46 ` [PATCH v4] " Rudy Rigot via GitGitGadget
2022-11-10 5:42 ` Eric Sunshine
2022-11-10 17:01 ` Rudy Rigot
2022-11-10 17:30 ` Eric Sunshine
2022-11-10 17:47 ` Rudy Rigot
2022-11-10 20:04 ` [PATCH v5] " Rudy Rigot via GitGitGadget
2022-11-15 16:39 ` Jeff Hostetler
2022-11-15 16:42 ` Rudy Rigot
2022-11-15 17:26 ` Eric Sunshine
2022-11-15 17:45 ` Rudy Rigot
2022-11-15 18:06 ` Eric Sunshine
2022-11-15 18:08 ` Rudy Rigot
2022-11-15 21:19 ` [PATCH v6] " Rudy Rigot via GitGitGadget
2022-11-21 5:06 ` Eric Sunshine
2022-11-21 15:54 ` Rudy Rigot
2022-11-21 16:17 ` Eric Sunshine
2022-11-22 16:52 ` Rudy Rigot
2022-11-22 17:18 ` Eric Sunshine
2022-11-22 17:24 ` Eric Sunshine
2022-11-22 17:29 ` Rudy Rigot
2022-11-22 17:40 ` Eric Sunshine
2022-11-22 18:07 ` Eric Sunshine
2022-11-22 19:19 ` Rudy Rigot
2022-11-22 19:48 ` Eric Sunshine
2022-11-22 16:59 ` [PATCH v7] status: modernize git-status "slow untracked files" advice Rudy Rigot via GitGitGadget
2022-11-22 22:07 ` [PATCH v8] " Rudy Rigot via GitGitGadget
2022-11-25 4:58 ` Junio C Hamano
2022-11-29 15:21 ` Rudy Rigot
2022-11-30 0:51 ` Rudy Rigot
2022-11-30 0:52 ` [PATCH v9] " Rudy Rigot via GitGitGadget
2022-12-01 6:48 ` Junio C Hamano
2022-12-01 15:16 ` Rudy Rigot
2022-12-01 22:45 ` Junio C Hamano
2022-12-01 22:57 ` Rudy Rigot
2023-05-11 5:17 ` [PATCH v8] " Eric Sunshine
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=221104.867d0byu5e.gmgdl@evledraar.gmail.com \
--to=avarab@gmail.com \
--cc=git@jeffhostetler.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=me@ttaylorr.com \
--cc=rudy.rigot@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).