git request-pull: Usage, Options & Common CI Errors
git request-pull produces a text summary asking someone to pull a published branch.
In email-based and mailing-list workflows, request-pull is how you announce that a branch is ready, including a shortlog and diffstat the maintainer can review before pulling.
What it does
git request-pull <start> <url> <end> writes a human-readable message summarizing the commits between <start> and <end> on the given URL, with a shortlog and diffstat, for a maintainer to act on.
Common usage
git request-pull v1.0.0 https://github.com/me/repo.git feature
git request-pull origin/main https://github.com/me/repo.git HEAD
git request-pull v1.0.0 git@github.com:me/repo.git my-branchOptions
| Argument | What it does |
|---|---|
| <start> | Base the maintainer already has |
| <url> | Public URL the commits are published at |
| <end> | Branch/tag to be pulled (default: HEAD) |
| -p | Include the patch in the output |
Common errors in CI
warn: No match for commit <sha> found at <url> / "Are you sure you pushed ‘<end>’ there?" - the branch is not actually published at the URL yet; push first. The <start> reference must be a real ancestor the maintainer can resolve, or the diff range is meaningless.
Using this in CI
CI checkouts are shallow and detached by default, which changes the answer this command gives you. Commands that read history, branch names, or tags need the checkout configured for it.
- uses: actions/checkout@v4
with:
fetch-depth: 0 # history, tags, and git describe all need this
- run: |
git rev-parse --is-shallow-repository # expect false
git rev-parse --abbrev-ref HEAD # prints HEAD when detached