AFAIK mr does not need much config, mostly just running `mr register` after `git clone`. When you do need to set config, the `mr config` command can help. All that said, I do have a lot of custom config :)
There is a `mr bootstrap` command for pulling a repo with a .mrconfig file in it, and then pulling a bunch of repos from there, here is an example usage:
Nice... I made "Bulk Git Ops" Bash functions to source into shell and tab-complete to invoke. (nb. I organise my sources like this: ~/src/{github,gitlab,bitbucket}/{usernames..}/{reponames..}).
Examples assume that repos you contribute to are spread across
remote hosts, and (hopefully) namespaced sanely. I organise my
sources as follows.
~/src/{github,gitlab,bitbucket}/{usernames..}/{reponames..}
QUERY: Count repos that are stale:
ls_git_projects ~/src/ | take_stale | count_repos_by_remote
QUERY: Count repos that are active (within 12 hours by default):
ls_git_projects ~/src/ | take_active | count_repos_by_remote
EXECUTE! Use 'xgit' to apply simple git commands to the given repos, with logs to STDERR/stty
ls_git_projects ~/src/bitbucket | xgit fetch # bitbucket-hosted repos
EXECUTE! Use 'proc_repos' to apply custom functions to, with logs to STDERR/stty
ls_git_projects ~/src/bitbucket | proc_repos git_fetch # all repos
ls_git_projects ~/src/bitbucket | take_stale | proc_repos git_fetch # only stale repos
ls_git_projects ~/src/bitbucket | take_active | proc_repos git_fetch # only active repos
EXECUTE! What's the current branch? Logs to STDERR/stty
ls_git_projects ~/src/bitbucket | proc_repos git_branch_current # all repos
EXECUTE! With logs redirected to hidden dir for logging (you must create it by hand first)
mkdir -p "${logdir}"
ls_git_projects ~/src/bitbucket | proc_repos git_branch_current 2>> "${logdir}/bulkops.log"
tail "${logdir}/bulkops.log"
reminds me of an project I made many years ago to manage dependencies in between repositories. So if project A was waiting for a fix in project B to be in production, you could draw a line between the two commits (from project A to project B) and get notified when the commit in project B gets into the "production" branch. And then merge and deploy your feature branch from project A.
Cool, I just had claude code write me something similiar this week to go through my immediate directories and get me this type of information on each one of this (since all of my git repos are under a single dir)
fun fact: check-projects is initially a nodejs script I wrote specifically for my projects few years ago;
My first usage to test out claude code was to generalize this script: cople hours later it was entirely rewritten with Go and and CI on github actions you see now here.
For working with many repos beyond pure status reporting there is Joey Hess's mr tool.
My only gripe is that configuration is manual and I wish there was an easy way fetch a set of repos from the well known forges into an mr config.
Oh, and I never figured out how to best work with it in a multi worktree per bare repo setup.
Just for completeness, there's also mu-repo: https://fabioz.github.io/mu-repo/
We've being using it for years. Very simple to setup.
AFAIK mr does not need much config, mostly just running `mr register` after `git clone`. When you do need to set config, the `mr config` command can help. All that said, I do have a lot of custom config :)
There is a `mr bootstrap` command for pulling a repo with a .mrconfig file in it, and then pulling a bunch of repos from there, here is an example usage:
https://wiki.debian.org/DebianInstaller/CheckOut
mr does have bare repo support, I haven't tried git multi-worktree stuff before though. I guess you would have to manually register each worktree.
Reminds me of myrepos, there are a lot of projects like this.
https://myrepos.branchable.com/ https://myrepos.branchable.com/related/
Also see https://github.com/fboender/multi-git-status which I've used happily for a few years.
It's a shell script (#!sh) and therefore easy as copy/paste to install.
Nice... I made "Bulk Git Ops" Bash functions to source into shell and tab-complete to invoke. (nb. I organise my sources like this: ~/src/{github,gitlab,bitbucket}/{usernames..}/{reponames..}).
ref: bulk-git-ops.sh in my repo https://github.com/adityaathalye/bash-toolkit/
This way:
"mr status" command gives status information of locally checked out repos. Refer https://myrepos.branchable.com/
this lists all modifications, when check-projects tells you one line if your project is WIP:
x uralys/web * M www
then you go work with your modifications on your project. https://github.com/rupa/z is perfect to go from projects to projects.
reminds me of an project I made many years ago to manage dependencies in between repositories. So if project A was waiting for a fix in project B to be in production, you could draw a line between the two commits (from project A to project B) and get notified when the commit in project B gets into the "production" branch. And then merge and deploy your feature branch from project A.
A fast, cross-platform CLI tool to check the git status of multiple projects organized by categories.
Run check-projects to see which of your projects have uncommitted changes, are ahead of remote, or have other git status indicators.
Cool, I wrote a similar tool but that let's users define their own tasks (comes with a tui as well) github.com/alajmo/mani.
things people do instead of having a monorepo
What if people work in different, totally unrelated projects and thus cant have the same repo?
my projects are for different stacks, different people. they sometimes are themselves monorepo;
the aim of check-projects is just to keep track of the work still not fully done and pushed.
Cool, I just had claude code write me something similiar this week to go through my immediate directories and get me this type of information on each one of this (since all of my git repos are under a single dir)
fun fact: check-projects is initially a nodejs script I wrote specifically for my projects few years ago;
My first usage to test out claude code was to generalize this script: cople hours later it was entirely rewritten with Go and and CI on github actions you see now here.