ghorg v1.11.15 - Repo Filter Hook And Bare Prune

ghorg v1.11.15 was published on 26 August 2026. The tag adds GHORG_REPO_FILTER_HOOK, so a clone run can pass the filtered repo list to an external executable and then clone whatever JSON comes back. That is the change that matters for org mirrors, backup jobs, and pipelines that already use ghorg as a bulk git fetch step.

The full release notes and downloads are on the GitHub release page.

GHORG_REPO_FILTER_HOOK points at an executable. The same setting is the --repo-filter-hook flag.

After ghorg fetches the remote list and applies its built in filters, it writes the remaining repos as a JSON array to the hook’s stdin. The hook must write a JSON array to stdout. That array becomes the clone list.

The hook runs last. It can drop repos. It can also mutate fields, including clone_branch. An empty array [] is valid and means clone nothing. Use this when match regex, prefixes, target repos, ghorgonly, and ghorgignore cannot express the rule. Team ownership, repo size, last activity, or an allowlist from an internal API are the usual cases.

If the hook is missing, exits nonzero, or writes invalid JSON, ghorg aborts the run. A broken hook does not fall through to an unfiltered clone.

A hook path with no path separator is resolved via PATH, not the current directory. A local script needs ./filter.sh or an absolute path.

The hook inherits the process environment. That includes GHORG_SCM_TYPE, GHORG_CLONE_TYPE, and credentials such as GHORG_GITHUB_TOKEN. The project documents that as intentional because the operator owns the executable. Treat the hook like any other token consumer. Do not point it at an untrusted binary.

Write progress or diagnostics to stderr. ghorg streams that through.

Match regex and topic filters are unchanged. The new piece is a last stage that can rewrite the clone list after those filters finish.

GHORG_PPROF and GHORG_TRACE are added in this tag for profiling clone runs. The matching flags are --pprof and --trace. Both default to false.

With GHORG_PPROF set, ghorg writes five pprof files in the directory the command is run from, not in the clone output directory:

  • ghorg-cpu.pprof
  • ghorg-heap.pprof
  • ghorg-goroutine.pprof
  • ghorg-block.pprof
  • ghorg-mutex.pprof

The CPU profile covers the clone. The heap, goroutine, block, and mutex files are snapshots taken when the clone finishes. Analyze them with go tool pprof. A typical start is go tool pprof ghorg-cpu.pprof.

GHORG_TRACE writes ghorg-trace.out in the same directory. Analyze it with go tool trace ghorg-trace.out. Trace files can get large on big clones. Leave this off on a scheduled backup unless that host has a disk budget for the file.

These flags do not change clone semantics. They are for operators who need to see where time and memory go on a large org clone. Set them in the environment or in $HOME/.config/ghorg/conf.yaml for a one off run, then turn them off.

The one bugfix in the notes is that bare repositories were skipped during pruning. Credit in the notes goes to psghahremani.

ghorg prune compares local clones against the remote list and removes local copies that are gone upstream. If bare clones were skipped, a deleted remote repo could remain on disk as a bare directory. That layout is common for mirrors and backups.

After v1.11.15, prune considers those directories. Leftover bare clones from deleted remotes can now be removed. Any workflow that treated the skip as accidental protection for bare clones that are no longer on the remote will now lose those dirs. If you keep mixed working trees and bare clones in the same output dir, run prune with confirmation before you let a job delete on its own.

The Changed, Deprecated, Removed, and Security sections in the notes are empty. There is no migration step listed. This is a patch tag.