On 10/23/2018 4:03 PM, Ævar Arnfjörð Bjarmason wrote:
[snip]
The --ahead-behind config setting stalled on-list before:
https://public-inbox.org/git/36e3a9c3-f7e2-4100-1bfc-647b809a09d0@xxxxxxxxxxxxxxxxx/
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.
