pullr

Safe, fast-forward pull every git repository under a directory.

Built for workspaces made of many independent repositories, where keeping everything current means cd-ing into each one.

$ pullr ~/work
+ api (main, 3 new commits)
+ web (main, 1 new commit, local changes reapplied)
~ docs (main, 2 commits held back because local changes conflict with them)
- scratch (main has no upstream)
x infra (main)
    diverged from upstream (behind 2, ahead 1): cannot fast-forward

Repos: 5  updated: 2  up to date: 0  dirty: 1  skipped: 1  failed: 1
Dirty: docs
Failed: infra

Install

# Homebrew
brew install kova1max/tap/pullr

# npm
npm install -g @kova1/pullr

To try it without installing anything:

npx @kova1/pullr --dry-run ~/work

Every release is also mirrored to GitHub Packages as @kova1max/pullr (GitHub requires the repo owner as scope). Installing from there needs a GitHub token, so the npm registry above is the easier choice.

What it will never do

pullr is built to be safe to run across a whole workspace without looking first. It will never:

• Create a merge commit. Pulls are fast-forward only.
• Touch a branch that has diverged from its upstream. It is reported as failed and left exactly as it was. Rebasing it is opt-in with --rebase, and a rebase that hits a conflict is aborted, leaving the repository as it was.
• Leave your changes half-merged, or lose them. When local edits or untracked files are in the way of an update, pullr stashes them, updates, and re-applies them on top. If they conflict with the incoming commits, it puts the repository back exactly as it was - same commit, same files, same staged and unstaged changes, no stash left behind - and reports it as dirty. Edits that don't touch incoming files are never stashed at all. --no-autostash skips the stash and just reports the repository as dirty.
• Touch a repository on a detached HEAD, or a branch with no upstream. Both are skipped.
• Enter a nested repository. Repositories inside another repository are left to their parent.
• Move a submodule off its branch. With --submodules, a submodule is only ever fast-forwarded on the branch it is on. (If you set git's submodule.recurse, pullr does what git pull does with it: checks submodules out at the recorded commit.)
• Follow symlinked directories.

Usage

pullr [options] [DIR]

Short options can be combined: -rs is -r -s, and -j8 or -rj 8 set the number of jobs.

Option	Default	Meaning
DIR	current directory	Where to look for repositories
-j, --jobs N	8	Work on up to N repositories in parallel. Output is buffered per repository and printed in discovery order, so it reads the same as a sequential run. With N > 1 git never prompts for credentials; use --jobs 1 for repositories that need an interactive login.
--max-depth N	2	How many directory levels below DIR to search. 0 = only DIR itself, 1 = DIR and its direct children, ...
-n, --dry-run		Show what a run would do without pulling, see below
-r, --rebase	off	Rebase local commits onto the upstream instead of refusing a diverged branch (git pull --rebase). A rebase that hits a conflict is aborted and the repository is left as it was.
--no-autostash		Don't stash local changes that are in the way of an update; report the repository as dirty instead. Autostash is on by default, see "What it will never do".
-s, --submodules	off	Also fast-forward each submodule that is checked out on a branch, see below
--no-color		Disable colored output. Also disabled when the NO_COLOR environment variable is set, or when output is not a terminal.
-V, --version		Print the version
-h, --help		Show help

Output

Each repository gets one line: + updated, = already up to date, ~ dirty (local changes conflict with the update, which is held back), - skipped, x failed (with the reason indented below it). Exits 1 if any pull failed, 2 on invalid arguments, 0 otherwise; a dirty repository is not a failure.

Dry run

pullr --dry-run shows what a run would do, without pulling:

$ pullr --dry-run ~/work
Dry run: nothing will be pulled.
+ api (main, 3 new commits)
= web (main)
x infra (main)
    diverged from upstream (behind 2, ahead 1): cannot fast-forward
- scratch (main has no upstream)

Repos: 4  would update: 1  up to date: 1  dirty: 0  skipped: 1  would fail: 1
Failed: infra

It runs git fetch in each repository first, so the answer reflects the remote as it is now, then prints the same lines a real run would. An update that would need to stash local changes shows as + ... , local changes to autostash, and with --rebase a diverged repository shows as + ... , 2 to rebase instead of x; whether re-applying or rebasing would conflict is only known by running it. Fetching only updates remote-tracking refs: the working tree and current branch are never modified. Exit codes match a real run.

Submodules

By default pullr updates a repository the way git pull does: submodules stay where they are, unless you set git's submodule.recurse, in which case they are checked out at the commits the parent now records, as git pull would.

--submodules is for working inside submodules. Each submodule that is checked out on a branch is treated as a repository of its own - fetched, fast-forwarded with the same rules, and listed under its parent:

$ pullr --submodules ~/work
+ app (main, 2 new commits)
  + app/lib/core (main, 5 new commits)
  - app/vendor/sdk (detached HEAD)

Submodules on a detached HEAD (git's default after git submodule update) are skipped, and uninitialized ones are left out.

How it compares

	pullr	gita	gitup	myrepos (mr)	mani
Needs	bash and git	Python 3.8+	Python 3.10+	Perl	Go binary
Finds repos	scans a directory	register first (gita add)	scans a directory	register first (~/.mrconfig)	register first (mani.yaml)
Pulls in parallel	8 at a time by default	all at once, no limit	no	opt-in	opt-in
Update	fetch + fast‑forward	git pull	fetch + fast‑forward	git pull	no built-in pull
Merge commits	never	depends on your git config	never	depends on your git config	depends on your command
Local changes in the way	stashed and reapplied; rolled back on conflict	git's error	skipped	git's error	-
Dry run	yes	no	no	no	prints commands

Why "8 at a time" and not "all at once". Many self-hosted git servers limit how many SSH connections can be opening at the same time; OpenSSH's default (MaxStartups 10:30:100) starts refusing them past 10. Fetching every repository at once then fails for reasons that have nothing to do with your repositories. On a self-hosted GitLab with 61 repositories, 16 parallel fetches produced 6-9 of those spurious failures and 32 produced 10-14, while 8 produced none. GitHub itself handled 64 at once without errors, so raise -j freely there.

License

MIT