Recommended configurations (was Re: [PATCH v1 2/2] reset: add new reset.quietDefault config setting)

From: Derrick Stolee <stolee@gmail.com>
Date: Oct 24, 2018, 15:48 UTC
Message-ID: <29db5fed-4556-277e-7aad-7ff3233550a9@gmail.com>
In-Reply-To: <87zhv4bfck.fsf@evledraar.gmail.com>

On 10/23/2018 4:03 PM, Ævar Arnfjörð Bjarmason wrote:

Show 19 quoted lines

> [snip]
> The --ahead-behind config setting stalled on-list before:
> https://public-inbox.org/git/36e3a9c3-f7e2-4100-1bfc-647b809a09d0@jeffhostetler.com/
>
> Now we have this similarly themed thing.
>
> I think we need to be mindful of how changes like this can add up to
> very confusing UI. I.e. in this case I can see a "how take make git fast
> on large repos" post on stackoverflow in our future where the answer is
> setting a bunch of seemingly irrelevant config options like reset.quiet
> and status.aheadbehind=false etc.
>
> So maybe we should take a step back and consider if the real thing we
> want is just some way for the user to tell git "don't work so hard at
> coming up with these values".
>
> That can also be smart, e.g. some "auto" setting that tweaks it based on
> estimated repo size so even with the same config your tiny dotfiles.git
> will get "ahead/behind" reporting, but not when you cd into windows.git.

Generally, there are a lot of config settings that are likely in the "if you have a big repo, then you should use this" category. However, there is rarely a one-size-fits-all solution to these problems, just like there are different ways a repo can be "big" (working directory? number of commits? submodules?).

I would typically expect that users with _really_ big repos have the resources to have an expert tweak the settings that are best for that data shape and share those settings with all the users. In VFS for Git, we turn certain config settings on by default when mounting the repo [1], but others are either signaled through warning messages (like the status.aheadBehind config setting [2]).

We never upstreamed the status.aheadBehind config setting [2], but we _did_ upstream the command-line option as fd9b544 "status: add --[no-]ahead-behind to status and commit for V2 format". We didn't want to change the expected output permanently, so we didn't add the config setting to our list of "required" settings, but instead created a list of optional settings [3]; these settings don't override the existing settings so users can opt-out. (Now that we have the commit-graph enabled and kept up-to-date, it may be time to revisit the importance of this setting.)

All of this is to say: it is probably a good idea to have some "recommended configuration" for big repos, but there will always be power users who want to tweak each and every one of these settings. I'm open to design ideas of how to store a list of recommended configurations and how to set a group of config settings with one command (say, a "git recommended-config [small|large|submodules]" builtin that fills the local config with the important settings).

Thanks, -Stolee

[1] 
https://github.com/Microsoft/VFSForGit/blob/7daa9f1133764a4e4bd87014833fc2091e6702c1/GVFS/GVFS/CommandLine/GVFSVerb.cs#L79-L104
     Code in VFS for Git that enables "required" config settings.

[2] 
https://github.com/Microsoft/git/commit/0cbe9e6b23e4d9008d4a1676e1dd6a87bdcd6ed5
     status: add status.aheadbehind setting

[3] 
https://github.com/Microsoft/VFSForGit/blob/7daa9f1133764a4e4bd87014833fc2091e6702c1/GVFS/GVFS/CommandLine/GVFSVerb.cs#L120-L123
     Code in VFS for Git that enables "optional" config settings.