On 2020-04-06 10:42:23-0400, Derrick Stolee <stolee@xxxxxxxxx> wrote: > Of course, not every platform has "cron" but that just means we need a > cross-platform way to launch Git processes on some schedule. That could > be a command that creates a cron job on platforms that have it, and on There's Unix system that doesn't have cron. People could use other scheduler mechanism. A lot of systemd users uses systemd-timer. I'm using snooze. Each of those set of utilities have different grammar and configuration. > Windows it could create a scheduled task instead. > > But what should we launch? It should probably be a Git command that > checks config for a list of repositories, then runs "the maintenance > command" on each of those repos. > > I'm inserting a break here to draw the eye to a new proposed design: > > --- > > Create a "git maintenance" builtin. This has a few subcommands: > > 1. "run" will run the configured maintenance on the current repo. This > should become the single entry point for users to say "please clean > up my repo." What _exactly_ it does can be altered with config. I'll > list some possibilities after listing the subcommands. > > 2. "run-on-repos" uses command-line arguments or config to launch "git > -C <dir> maintenance run" for all configured directories. The > intention is that this is launched on some schedule by a platform- > specific scheduling mechanism (i.e. cron). So, IIUC, Git will have a _hard_ dependencies on cron on *nix? Else, we're gonna received a bug-report that some tools doesn't work? I've seen some bug report in our distro that "git add -p" doesn't work like documented, because it's in "git-perl" packages. When we merge "git-perl" back to git, other people (who never use "git add -p" and git-sendemail) complain why does we add a hard dependencies on perl to git. > (This subcommand could use a better name.) > > 3. "schedule" adds the current repository to the configured list of > repositories for running with "run-on-repos". It will also initialize > the platform-specific scheduling mechanism. This may be to start the > schedule for the first time OR to update how frequent "run-on-repos" > is run, as appropriate. > > 4. (OPTIONAL) "mode <mode>" adjusts the config for the current repo to > change the type of maintenance requested for this repo. For example, > "simple" could just run "git gc --auto" using a normal range. > "incremental" could run the maintenance tasks from this series. > Finally, "server" could run maintenance tasks as if we are serving > the repo to others, so we repack aggressively with full bitmaps, and > more frequently. -- Danh
