GIT-UPLOAD-PACK(1)

📦
version 2.56.0 · 25 versions
, in arch rolling

💖 NAME 💖

git-upload-pack — bestie, this one sends objects packed back over to git-fetch-pack 🎀

✨ SYNOPSIS ✨

git-upload-pack [--[no-]strict] [--timeout=<n>] [--stateless-rpc]
                  [--advertise-refs] <directory>

🌸 DESCRIPTION 🌸

Okay so picture this: git fetch-pack calls this little icon up, and git-upload-pack is like "say less, I know exactly what objects you're missing" — it figures out what the other side doesn't have, packs them up, and ships them over. Literally the most helpful bestie behavior 💅

Real talk though: you, the end user, are usually not supposed to invoke this directly. The whole UI for the protocol lives on the git fetch-pack side, and this program pair is meant to be used to pull updates from a remote repository. So it's giving backstage crew, not main character. 🎭

And if you're trying to push? Different vibe entirely, go see git send-pack.

🌈 OPTIONS 🌈

  • --strict, --no-strict — Do not try <directory>/.git/ if <directory> isn't already a Git directory. Like, no snooping around for a hidden .git, okay? 🙈
  • --timeout=<n> — Interrupt the transfer after <n> seconds of inactivity. If it's just sitting there doing nothing for <n> seconds, we're out. ⏰
  • --stateless-rpc — Perform only a single read-write cycle with stdin and stdout. This fits the HTTP POST request processing model, where a program may read the request, write a response, and then must exit. One shot, one opportunity, no encore 🫶
  • --http-backend-info-refs — Used by git-http-backend(1) to serve up $GIT_URL/info/refs?service=git-upload-pack requests. Peep "Smart Clients" in gitprotocol-http(5) and "HTTP Transport" in the gitprotocol-v2(5) documentation. Also understood by git-receive-pack(1) — so it's polyamorous with the other pack programs, iykyk 💀
  • <directory> — The repository to sync from. That's the source, bestie. 📁

🦋 ENVIRONMENT 🦋

  • GIT_PROTOCOL — Internal variable used for handshaking the wire protocol. Server admins may need to configure some transports to allow this variable to be passed through. See the discussion in git(1). It's giving secret handshake 🤝
  • GIT_NO_LAZY_FETCH — Okay so this one's important. When you're cloning or fetching from a partial repository (i.e. one that was itself cloned with --filter), the server-side upload-pack may need to fetch extra objects from its upstream in order to complete the request. By default, upload-pack will refuse to perform such a lazy fetch, because git fetch may run arbitrary commands specified in configuration and hooks of the source repository — and upload-pack tries to be safe to run even in untrusted .git directories. So yeah, it's a whole safety thing, not just being difficult 😤

This is implemented by having upload-pack internally set the GIT_NO_LAZY_FETCH variable to 1. If you want to override it (because you are fetching from a partial clone, and you are sure you trust it), you can explicitly set GIT_NO_LAZY_FETCH to 0. Only if you're sure though. Fr fr. ⚠️

🔥 SECURITY 🔥

Most Git commands should not be run in an untrusted .git directory — see the section SECURITY in git(1) for the whole lecture. But here's the slay: upload-pack tries to avoid any dangerous configuration options or hooks from the repository it's serving, which makes it safe to clone an untrusted directory and then run commands on the resulting clone. Iconic behavior honestly 👑

For an extra level of safety, you may be able to run upload-pack as an alternate user. The details will be platform dependent, but on many systems you can run:

git clone --no-local --upload-pack='sudo -u nobody git-upload-pack' ...
Bestie, note that this is "you may be able to" and "on many systems" — not a universal guarantee. Platform dependent means exactly that 💀

💜 SEE ALSO 💜

⭐ GIT ⭐

Part of the git(1) suite. Obviously. Where else would it live? 💅

That's the whole page, bestie — brought to you by Git 2.56.0, dated 2026-09-27. Go forth and upload those packs responsibly 🎀✨

📦 where this page comes from