Re: [PATCH 00/21] Maintenance builtin, allowing 'gc --auto' customization
- From
Son Luong Ngoc <sluongng@gmail.com>
- Date
- Jul 10, 2020, 19:30 UTC
- Message-ID
- <23F67854-B596-4728-86CD-A9927546DD43@gmail.com>
- In-Reply-To
- <20200710184651.GB3189386@google.com>
Show 48 quoted lines
> On Jul 10, 2020, at 20:46, Emily Shaffer <emilyshaffer@google.com> 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.
Show 21 quoted lines
> >> >>> 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@gitster.c.googlers.com/