From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-3.3 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by dcvr.yhbt.net (Postfix) with ESMTP id 280AA1F910 for ; Fri, 4 Nov 2022 08:57:23 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="VXf4Mh2u"; dkim-atps=neutral Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230205AbiKDI5G (ORCPT ); Fri, 4 Nov 2022 04:57:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60446 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230182AbiKDI5F (ORCPT ); Fri, 4 Nov 2022 04:57:05 -0400 Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D64B828720 for ; Fri, 4 Nov 2022 01:57:03 -0700 (PDT) Received: by mail-ej1-x632.google.com with SMTP id y14so11509539ejd.9 for ; Fri, 04 Nov 2022 01:57:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:message-id:in-reply-to:user-agent:references:date :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=So9DiouScP5Rmog91yL4QtgvnubcX5E0J0xqiF20nZA=; b=VXf4Mh2upecOrwSdst9pc5lnggDIQEtjT2Hb02sVaLUCmJ18PJ5ptYZ5dBmpP3rhKi 8bmNll7kkazjOQHuiFXtQeA7jGb/k/sB2LMqEF1dBfCQvi59g4Wof1/tcDCay31Nu6To eMLo0oy7/1egGgVfSZ2/da+bVoVsXfH4JUzA9Pk1MbueORjE69bEecZGbWOmGbzBjWgM 9zdnbD1zb5gpmfH+f4r5so9wZB4z0TAcEXQyUexJFIcA0SlzqCU7UssW6zC6LW9RxJed bMu+0nWGKISZe0u49BrWKsBklZzuMbVrFbhbzh5laWx6xg3FZmk9L1H9RkprZLcCP4AB b41w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:in-reply-to:user-agent:references:date :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=So9DiouScP5Rmog91yL4QtgvnubcX5E0J0xqiF20nZA=; b=mDJqLC318s24ugE3IZYlyfpnPKBIiK2GCVKsI32T5YQXYhmfr6mrvOrfN/pkOiaydi nAdIjzI39Sw4Ee3zT4UbceeY5Lx2JgRYk92zDpQb3o/hXIRYFD51fivOx/RK86RbfDU7 JPrRz8RcYJ5gXXg+/+WfQIcGV9Kx+PeJzLIkxCykGE0BPEinVlex7M8f6zpOmcUevZPO 6mUtbjtJduUeS9AjXb8ELifERXE9PpHsRDjty5PgZwl+Ue2DaYEQiWLziCMQDDGR8FMC UTQmVJhZeLKuc/vkcX9LwSTg0m2He2Z5HQ6nZJXN8N2MuWpSUWshQ9wpotAfQcwaUPbt BsHg== X-Gm-Message-State: ACrzQf033VgE8muJQDWK5q1QsprS8nMEQjyWSyjOaR2TwgMBkdMTj1sY B/eJSeF07zkcg2nc0+Rmn451Qvu4sbpksA== X-Google-Smtp-Source: AMsMyM6bog6FEePfjyTn2x7DkyW9SWFjSRNeIUkAYMeL59TggqHXJ5Yt/QIfD2RZgZFrZ9eMidEeNw== X-Received: by 2002:a17:907:75e4:b0:7ae:2336:9d17 with SMTP id jz4-20020a17090775e400b007ae23369d17mr5946892ejc.7.1667552222180; Fri, 04 Nov 2022 01:57:02 -0700 (PDT) Received: from gmgdl (j84064.upc-j.chello.nl. [24.132.84.64]) by smtp.gmail.com with ESMTPSA id g17-20020a170906539100b007ae1e528390sm1498919ejo.163.2022.11.04.01.57.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Nov 2022 01:57:01 -0700 (PDT) Received: from avar by gmgdl with local (Exim 4.96) (envelope-from ) id 1oqsVZ-00DDxp-0l; Fri, 04 Nov 2022 09:57:01 +0100 From: =?utf-8?B?w4Z2YXIgQXJuZmrDtnLDsA==?= Bjarmason To: Rudy Rigot Cc: Taylor Blau , Jeff Hostetler , Rudy Rigot via GitGitGadget , 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 References: <8abc5272-4e01-e793-5155-ea116e9ad4fd@jeffhostetler.com> User-agent: Debian GNU/Linux bookworm/sid; Emacs 27.1; mu4e 1.9.0 In-reply-to: Message-ID: <221104.867d0byu5e.gmgdl@evledraar.gmail.com> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org 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.