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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

> 
> > 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.

 - Emily



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux