On 10/5/2020 3:57 PM, Martin Ågren wrote: > On Mon, 5 Oct 2020 at 15:07, Derrick Stolee via GitGitGadget <gitgitgadget@xxxxxxxxx> wrote: >> To make this process extremely simple for users, assume a default >> schedule when no 'maintenance.<task>.schedule' or '...enabled' config >> settings are concretely set. This is only an in-process assumption, so >> future versions of Git could adjust this expected schedule. > > This obviously makes sense to me. ;-) One thing it does mean though is > that something like this: > > $ git maintenance register > # Time goes by... > # Someone said to try this: > $ git config --add maintenance.commit-graph.schedule hourly > $ git config --add maintenance.commit-graph.enable true > # That could have been a no-op, since we were already on > # such an hourly schedule, but it will effectively turn off > # all other scheduled tasks. So some time later: > # -- Why are my fetches so slow all of a sudden? :-( > > That could be different if `git maintenance register` would turn on, > say, `maintenance.baseSchedule = standard` where setting those > `maintenance.commit-graph.*` would tweak that "standard" "base > schedule" (in a no-op way as it happens). Thank you so much for your detailed feedback! This is an excellent point and I will be sure to account for it when I have time to carefully examine the options and these kind of workflows. Right now, I'm a bit underwater getting ready for the v2.29.0 release (in microsoft/git, Scalar, and VFS for Git) but I will revisit this as my main focus after this release cycle. I have not forgotten about this topic!!! > As mentioned above, I end with some minor suggestions. I really appreciate the effort you put in to this fixup. Thanks, -Stolee
