Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: Gita – a CLI tool to manage multiple Git repos (github.com)
79 points by nosarthur on Feb 4, 2019 | hide | past | favorite | 36 comments

One thing this project does really well is to start the readme with a screenshot. I open the link, scroll down to the readme, and I immediately see what sort of user interface/experience I will get. Some commenters have noted that Gita is similar to other multi-repo tools, but both Repo and wstool are more effort to evaluate, because their readmes don't have pictures.

Nice, but is there a way to just run any command? I.e. just `gita <optional repo names/paths> <pass entire command line git -C repodir>`. This has advantages in that you don't have to go round via a command file, don't have to keep it synced across machines, don't have to remember what you put in the file etc, and can just use the git syntax which already took long enough to learn by heart :P

I've used multiple multiple repository tools and in the end all I happen to use is one (usually versioned) file to store a list of repositories and then a command which just loops over all repos and applies anything to it. If I need custom commands I use git aliases so that works both for normal git and whatever tool used.

    → cat ~/bin/git-all

    # Exit on error. Append "|| true" if you expect an error.
    set -o errexit
    # Exit on error inside any functions or subshells.
    set -o errtrace
    # Do not allow use of undefined vars. Use ${VAR:-} to use an undefined VAR
    set -o nounset
    # Catch the error in case command1 fails (but command2 succeeds) in `command1 |command2`
    set -o pipefail
    # Turn on traces, useful while debugging but commented out by default
    # set -o xtrace

    help() {
      cat <<EOF

    usage: git all <any-git-command>

    Runs the git command for all repositories in the current directory.


      What just happened?
        git all log -1 --oneline

      What am I doing now?
        git all status --short --branch

      What is everything I'm working on?
        git all branch -vv

    banner() {
      echo -e "\\033[1m=== $1 ===\\033[0m"

    main() {
      if (( $# < 1 )); then
        exit 1

      folders=$(find . -maxdepth 2 -name .git -print0 | xargs -0 -n1 dirname)
      for folder in $folders;
        banner "$folder"
        git -C "$folder" "$@" || true

    main "$@"

Missed this reply, but yes, that's what I'm talking about!

This is an interesting idea. I never thought about it before. My previous thinking is that if something really complex needs to be done, then I will go to that directory.

But I do see the convenience in your proposal

Version 0.7.0 supports a super mode, which delegates any git command/alias. The usage is

gita super <repo-name> <any command/alias>

For example:

gita super repo2 commit -am 'fix a bug'

Another similar tool is myrepos (it supports other VCSen too). There are several other similar tools, see the related software section of the myrepos website:


I use myrepos and I like it a great deal.

mr register in the root of a git dir.

then `mr status` from home will show the state of all repo's registered, it's handy at the eod to see what repos you've touched but not committed.

Now I have referred myrepos on gita's homepage too

thanks for referencing gita!

I wrote a similar tool (along with some other git helpers) a while ago: https://github.com/tkrajina/git-plus. Note that there is another (more popular) git-plus repository used in Atom. My own has nothing to do with it (but it's older).

Isn’t this what “repo” [1] does?

[1] https://source.android.com/setup/develop/repo

didn't know this tool before. I will give it a try. Thanks!

Cool, new tooling!

I currently use a mix of mu-repo [1] and uncommitted [2]

[1]: http://fabioz.github.io/mu-repo/

[2]: https://github.com/brandon-rhodes/uncommitted

The biggest problem with multiple repositories is to manage consistent versions (commits).

For example, let's say that I have a release 1.0, which consists of a bunch of commit IDs of various repositories. How do I go back to that release without manually checking out the specific commit ID in each repo?

We use tags for that. Upon each release all repos get the same tag. Alternatively with tools like mr [1] you can for each release keep a .mrconfig somewhere which keeps the commit SHA for each repo (not 100% sure if mr can create such file by itself, but it's not really hard) so that if you do a fresh clone it checks out each repo at the correct commit.

[1] https://linux.die.net/man/1/mr

There is a mr/myrepos plugin that adds some automation for remembering the currently checked out commit:


Great tool! It’s nice we have one more tool to choose from. Each program has their own UX so I don’t see a new contender as a bad thing.

wstool (https://github.com/vcstools/wstool) is a tool for managing a workspace of multiple heterogenous SCM repositories.

Very convenient. I have used it for ROS projects with multiples SCM

Can you put up an asciinema demo pls

Isn't this what repo does ?

Or just have a monorepo :)

Operations on monorepos can be so slow that having multiple copies checked out (e.g. different branches) is a thing (ideally using worktrees).

I hate to say it but because I don't feel comfortable with git enough whenever I am about to do anything outside of my comfort zone I make a hard copy of my whole directory just to be sure if I get myself into a FUBAR state I can delete the FUBAR'd directory and copy it again. This has saved me many a headache. Also gives me a fresh state from which to ask for help from. Anytime the word rebase is mentioned my coworkers shriek.

Have you ever had a look at the combination of 'git reflog' and 'git reset --hard <ident>'? You can find the point before you did the uncomfortable operation and restore your state to exactly then. Saves having to make that backup copy (which, again, can be slow for a big repo).

Neither of those saves the working directory, though. So uncommitted work "feels" at risk while typing unfamiliar git commands.

(I now consider myself pretty good with git as a result of being forced to learn gerrit, but I also still remember the early painful days)

True, that's a good point.

You should really work through some Git tutorials.

I haven't done that since using SVN 10 years ago.

`git {branch,diff,stash}` should be all you need for this.

Especially working with the stash will be a big productivity boost for you.

Most of what I do is handled by my tooling for me. It's when I have to do more than just the basics that UI tools somewhat fall short. I prefer the UI that JetBrains IDE's give because I can see visually what I am about to commit. I've made a lot less mistakes than my colleagues who either don't pay attention to the UI or swear by the command line but still miss simple things quite often, the worse I do is a typo here or there which a command line approach would of never saved me from either.

To be fair I don't even remember anymore when I've had to do anything extensive, it's been quite a while. I'm even able to handle merge conflicts right away from within my editor.

This is one remaining huge advantage of centralised VCS systems which has been overlooked in the fad for git.

Did you just call git a fad? The vast majority of software in version control is in git, including some of the largest and most important open source projects.

What else do you think is a fad? Linux? C?

Evidence of widespread adoption is not evidence that something is not a fad. It might even be the evidence that it is a fad.

Faddishness is in the process of adoption. Why is the vast majority of software using git? Is it really the most suitable for their use case? Is it really the most usable, given the notoriously poor orthogonality of the CLI? Or is the adoption driven by adoption of github and git as the new "default"?

I don't follow, what's the specific advantage here? And just for context, we use both git and a cvs (yes, it's still going!) at day job. Both are pretty slow.

Since a centralised system doesn't carry all the history with every checkout, the checkouts are smaller and there's less risk of running out of SSD space with a large monorepo. It's also quicker to make a new one. svn/p4 will let you checkout a subtree of a "monorepo". p4 in particular is pretty fast, although as a closed source CASE tool its days must be numbered.

(re: carrying all the history, I used to work somewhere where they checked the build artefacts in to svn on every release build. A naive "git svn" import was in the 10s of gigabytes.)

We don't have space issues on our machines but you are right, you don't need multiple copies of the entire history and that's why I suggested the worktree feature.

Thanks for suggesting that, I'd not realised it was possible.

Applications are open for YC Winter 2021

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact