## TL;DR
The push is too large for some limit in the chain: the HTTP server, a proxy, or git's own buffer. Raise `http.postBuffer`, push in smaller chunks, and move big binaries to LFS. The push succeeds once every hop accepts the size.

## Error
```text
git: error: RPC failed; HTTP 413 curl 22 on push
```

## Steps
1. Raise the client buffer: set `http.postBuffer` to a larger value (for example 524288000) in the repo or global git config. Expected: the client stops chunking prematurely.
2. Push in smaller pieces: push a few branches or a limited commit range at a time. Expected: each smaller push succeeds, isolating whether size is the only issue.
3. Move large files to Git LFS: track binaries with LFS so the push carries pointers, not blobs. Expected: push size collapses.
4. Check server and proxy limits: reverse proxies and hosting providers cap request bodies (the 413 originates there as often as in git). Expected: the server-side limit raised or bypassed.
5. Retry the full push. Expected: it completes without RPC failure.

## When to use
- `git push` fails with HTTP 413 / RPC failed
- First push of a repo with large history or binaries
- Pushes through proxies with body limits

## When not to use
- 401/403 on push (authentication)
- "Repository not found" (wrong remote)

## Tool compatibility
- git `http.postBuffer`; Git LFS; reverse-proxy body limits

## Variant phrasings
### git push rpc failed http 413
Raise `http.postBuffer` and check the proxy's body limit; the 413 comes from the chain, not just git.

### push too large git
Split the push and LFS the binaries; smaller pushes isolate the limit.

## Why it happens
A push is one big HTTP POST, and every hop (git client buffer, proxy body limit, server request cap) enforces its own maximum. The 413 names the HTTP layer, but the fix is finding which hop's limit is smallest and raising it (or shrinking the push).

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_KYUmJStcHpPGPLOEqbTQKg