> On Jul 10, 2020, at 20:46, Emily Shaffer <emilyshaffer@xxxxxxxxxx> wrote: > > On Thu, Jul 09, 2020 at 07:45:47PM -0400, Derrick Stolee wrote: >> >> On 7/9/2020 7:16 PM, Jeff King wrote: >>> 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. > > I'm glad I wasn't the only one super geeked when I read this idea. I'd > use the heck out of this in my .bashrc too. Sounds awesome. I actually > had a short-lived fling last year with a script to summarize my > uncommitted changes in all repos at the beginning of every session > (dropped because it became one more thing to gloss over) and could have > really used this command. I was planning to build a CLI tool that help manage multiple repos maintenance like what was just described here. My experience using my poor-man-scalar [1] bash script is: For multiple repositories, the process count could get out of control quite quickly and there are probably other issues that I have not thought of / encountered... There is definitely a need to keep all the repos updated with pre-fetch and updated commit-graph, while staying compact / garbage free. Having this in Git does simplify a lot of daily operations for end users. > >> >>> 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. > > Oh, I like this idea a lot. Then I can do something silly like > > alias reproclone="git clone --no-maintainenance" > > and get the benefits on everything else that I plan to be using > frequently. This started to remind me of automatic updates in some of the popular OS. Where download/install/cleanup update of multiple software components are managed under a single tool. I wonder if this is the path git should take in the 'new world' that Junio mentioned. [2] But I am also super geeked reading this. :) > > - Emily Regards, Son Luong. [1]: https://github.com/sluongng/git-care [2]: https://lore.kernel.org/git/xmqqmu48y7rw.fsf@xxxxxxxxxxxxxxxxxxxxxx/
