$ mani exec --all --output table --parallel 'find . -type f | wc -l'
  
   Project            | Output
  --------------------+--------
   example            | 31016
   pinto              | 14444
   dashgrid           | 16527
   template-generator | 42

https://github.com/alajmo/mani

> ⬆⬆ - Diverged from remote

This is an obscure and confusing way of representing it. At the very least, I’d expect the addition of ⬇ to mean behind remote, and then ⬇⬆ to mean diverged (since it is logically just “both behind and ahead”).

For my part, I prefer a notation like “-4+5” to mean “4 commits behind, 5 commits ahead”, produced in this way in my $RPROMPT:

  commits_behind=$(git log --oneline ..@{u} 2> /dev/null | wc -l || echo 0)
  commits_ahead=$(git log --oneline @{u}.. 2> /dev/null | wc -l || echo 0)
  if [ $commits_behind -gt 0 -o $commits_ahead -gt 0 ]; then
      echo -n " %{\x1b[33m%}"
      [ $commits_behind -gt 0 ] && echo -n -$commits_behind
      [ $commits_ahead -gt 0 ] && echo -n +$commits_ahead
  fi

https://myrepos.branchable.com/ https://myrepos.branchable.com/related/

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.

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.

gh repo list --json url,name -q '.[] | "mr --config .mrconfig config " + .name + " " + .url' | sh

You could probably do it with xargs or similar too.

https://github.com/skx/github2mr

But to be honest given the regular naming you might as well have a simple perl/ruby script to just read a list of names from STDIN and output the local directory-path, and remote.

We've being using it for years. Very simple to setup.

It's a shell script (#!sh) and therefore easy as copy/paste to install.

ref: bulk-git-ops.sh in my repo https://github.com/adityaathalye/bash-toolkit/

This way:

  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"

I made a git exec command for that. It executes a command on multiple repos.

So to see the status of your local repositories cloned in the code directory of your home directory

´´´bash

export GIT_X_REPOS_FILE=~/code

git exec status

´´´

Code: https://github.com/gerardnico/git-x/blob/main/bin/git-exec

Doc: https://github.com/gerardnico/git-x/blob/main/docs/bin-gener...

Run check-projects to see which of your projects have uncommitted changes, are ahead of remote, or have other git status indicators.

https://github.com/r0ze-at-github/git-map

https://github.com/garden-rs/garden

[1] http://gitlab.com/garden-rs/garden

[1]: https://github.com/nosarthur/gita/

https://gerrit.googlesource.com/git-repo

  ls | xargs -I % sh -c 'cd %; pwd; git status -s'

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.

  ls | xargs -I % sh -c 'cd %; pwd; [[ $(git status -s) ]] && echo WIP || echo clean'

I do not need a CLI tool. I can come up with a very simple script or even an one-liner (like you just did) to achieve what I want.

Worth noting that neovim shows some git status when editing a file inside a git repository, and there are ways to do the same from your shell.

FWIW, I think this project was vibe coded with an LLM, but if it works, it works, so it makes no difference to me. The only reason I mentioned it is that "vibe coding" is not inherently bad. I do not even like the term. If you "vibe code" without knowledge, then yeah, it is bad, just as bad as a shitty developer writing code is.

This sort of response to complex solutions used to be more prevalent on HN. When I got downvoted I was like "..this is the end isn't it" :P Maybe the unix way is a dying strategy IDK, but you give me hope.

> FWIW, I think this project was vibe coded with an LLM, but if it works, it works, so it makes no difference to me.

I did not realise that, I'd be far more worried about running it than most human coded projects out of fear of it doing something destructive. Not that humans don't make mistakes, but at least they have a mental model and intent. I suppose it depends on the definition of "vibe coded" I've heard some people talk about sending the LLM off into a loop and then trying to use the result, whereas if you are just using it as a more powerful autocomplete and playing captain then that's a lot better.

As for the LLM part: I have written a couple of projects with the help of LLMs and it works perfectly! I know what I wanted it to do and how, and I did extensive testing, and I am familiar with the whole code, of course. The problem arises when people who "vibe code" do not have the knowledge to begin with. It ended up writing code that I would write because of me. :D It just wrote it quicker, that is all. Ultimately I would have written the same code, but it would have taken me a bit more time because I would have had to read documentation first (which I do not mind, I love doing it).

  sh: 1: [[: not found

  ls | xargs -I % bash -c 'cd %; pwd; [[ $(git status -s) ]] && echo WIP || echo clean'

the aim of check-projects is just to keep track of the work still not fully done and pushed.

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.