Proposal: official GitHub Action wrapper for git-sync

[mvanhorn]

Problem

git-sync is a one-shot CLI explicitly meant to run "from cron, CI, a worker, or another service" (README FAQ). There is no first-party GitHub Action today. The dominant alternative is pixta-dev/repository-mirroring-action (269 stars), which uses native git clone-and-push and so cannot benefit from the streaming relay this project was built around.

Proposal

Ship a composite Action at the repo root (action.yml) that downloads the released binary for the runner's OS/arch and executes it with user-supplied inputs.

Example usage:

- uses: entireio/git-sync@v0.4.2
  with:
    source: https://github.com/${{ github.repository }}.git
    target: https://gitlab.com/example/mirror.git
    target-token: ${{ secrets.GITLAB_TOKEN }}
    branch: main,release
    tags: 'true'
    prune: 'true'

Why composite

• The CLI is a single static binary, no JS runtime needed
• Composite supports Linux, macOS, and Windows runners (Docker Actions are Linux-only)
• Versioning maps cleanly to release tags (@v0.4.2)
• The team already publishes per-OS / per-arch artifacts via GoReleaser, so install.sh just downloads and verifies SHA256 from checksums.txt

Open questions for maintainers

1. Versioning policy: do you want major-tag aliases (@v0, @v1) maintained alongside specific tags (@v0.4.2)? GitHub Marketplace conventions suggest both.
2. Action location: at the repo root (action.yml) so uses: entireio/git-sync@v0.4.2 works directly, or in a sibling repo (entireio/git-sync-action)? Repo-root is simpler but couples Action releases to CLI releases.
3. Marketplace listing branding: any existing icon / color preferences? I defaulted to git-merge / purple.
4. JSON output forwarding: I planned to expose the JSON result as a step output when --json is set. Any concerns about leaking sensitive ref names into workflow logs?

The existing GoReleaser checksums.txt path is what install.sh would consume; no release pipeline changes needed.

[Soph]

1. I think doing versioning separate sounds better to me. This way we can change the action to a new params format in the future and otherwise it would always install latest (or a param can define the version of the cli to install)
2. Yeah we should do a separate repo
3. Will take a look
4. I wonder what the use case would be where I run the action on a public repo but use it to sync none private repos. If everything is public the refs are known anyway?

[mvanhorn]

Thanks Soph! Quick note up front: nothing is coded yet, this was a research and design pass against the README/CHANGELOG and the marketplace alternatives. Wanted to surface questions before writing.

On your answers:

1. Separate versioning makes sense. Default install to the matching action tag with a version: input override.
2. Separate repo at entireio/git-sync-action works.
3. No rush on branding.
4. Fair point. For the standard case (mirror your own public repo) refs aren't secret. The niche case I had in mind is a public-repo workflow syncing a private source or target where refs end up in the public Actions log. Rare enough I'd default --json on and mention the caveat in the README.

Happy either way:

A. I draft it on a fork (or a side branch here) so your team can lift it cleanly into the new repo.
B. Hand the plan over and your team builds from scratch.
C. Park it for now if it's not a priority. No pressure.

Plan covers install.sh with checksum verification, action.yml shape, multi-OS support, and Marketplace listing notes if any of it is useful.