Re: [PATCH 00/21] Maintenance builtin, allowing 'gc --auto' customization

From: Derrick Stolee <stolee@gmail.com>
Date: Jul 9, 2020, 23:45 UTC
Message-ID: <28c72d69-f524-7c4f-4cc3-847ca91cad33@gmail.com>
In-Reply-To: <20200709231624.GE664420@coredump.intra.peff.net>

On 7/9/2020 7:16 PM, Jeff King wrote:

Show 32 quoted lines

> On Thu, Jul 09, 2020 at 08:43:48AM -0400, Derrick Stolee wrote:
> 
>>>> Is it infeasible to ask for 'git maintenance' to learn something like
>>>> '--on /<path-to-repo> --on /<path-to-second-repo>'? Or better yet, some
>>>> config like "maintenance.targetRepo = /<path-to-repo>"?
>>
>> Sorry that I missed this comment on my first reply.
>>
>> The intention is that this cron entry will be simpler after I follow up
>> with the "background" part of maintenance. The idea is to use global
>> or system config to register a list of repositories that want background
>> maintenance and have cron execute something like "git maintenance run --all-repos"
>> to span "git -C <repo> maintenance run --scheduled" for all repos in
>> the config.
>>
>> For now, this manual setup does end up a bit cluttered if you have a
>> lot of repos to maintain.
> 
> I think it might be useful to have a general command to run a subcommand
> in a bunch of repositories. Something like:
> 
>   git for-each-repo --recurse /path/to/repos git maintenance ...
> 
> which would root around in /path/to/repos for any git-dirs and run "git
> --git-dir=$GIT_DIR maintenance ..." on each of them.
> 
> And/or:
> 
>   git for-each-repo --config maintenance.repos git maintenance ...
> 
> which would pull the set of repos from the named config variable instead
> of looking around the filesystem.

Yes! This! That's a good way to make something generic that solves the problem at hand, but might also have other applications! Most excellent.

> You could use either as a one-liner in the crontab (depending on which
> is easier with your repo layout).

The hope is that we can have such a clean layout. I'm particularly fond of the config option because users may want to opt-in to background maintenance only on some repos, even if they put them in a consistent location.

In the _far_ future, we might even want to add a repo to this "maintenance.repos" list during 'git init' and 'git clone' so this is automatic. It then becomes opt-out at that point, which is why I saw the _far, far_ future.

Thanks, -Stolee