GIT-FETCH-PACK(1)

πŸ’… GIT-FETCH-PACK(1) β€” the girlies' guide to git-fetch-pack

okay so bestie, welcome to git-fetch-pack β€” it's a git(1) suite girlie (more on that at the bottom 🫢). Grab a strawberry drink πŸ“ and let's get into it.


✨ NAME ✨

git-fetch-pack β€” receive missing objects from another repository. literally just "gimme the stuff I don't have yet" energy πŸ’–


🌸 SYNOPSIS 🌸

git fetch-pack [--all] [--quiet|-q] [--keep|-k] [--thin] [--include-tag]
        [--upload-pack=<git-upload-pack>]
        [--depth=<n>] [--no-progress]
        [-v] <repository> [<refs>...]

πŸ¦‹ DESCRIPTION πŸ¦‹

so like, real talk: usually you wanna use git fetch, which is the higher-level wrapper of this command. that's the main character. this one is the lowkey backstage icon doing the actual work πŸ’…

What happens: it invokes git-upload-pack on a possibly remote repository and asks it to send over the objects that are missing from this repo, so the named heads get updated. The list of commits you already have locally? Found by scanning your local refs/ hierarchy, then sent to the git-upload-pack running on the other end. no cap.

And here's the part where it gets a little dramatic 😭 β€” when the local side doesn't have a common ancestor commit, this command degenerates to download everything to complete the asked refs from the remote side. like, the whole thing. rip to your bandwidth.


πŸŽ€ OPTIONS πŸŽ€

  • --all β€” fetch all remote refs. everything. the whole wardrobe ✨
  • --stdin β€” take the list of refs from stdin, one per line. And if you also passed refs on the command line alongside this option? then the stdin refs get processed after the ones on the command line. order matters, bestie.
and if --stateless-rpc is specified together with this option, then the list of refs must be in packet format (pkt-line). Each ref must be in a separate packet, and the list must end with a flush packet. non-negotiable πŸ’€
  • -q, --quiet β€” passes the -q flag to git unpack-objects, which makes the cloning process less verbose. it's giving "girl, please stop narrating" πŸ™ˆ
  • -k, --keep β€” doesn't invoke git unpack-objects on the received data; instead it creates a single packfile out of it and stores it in the object database. And if you provide it twice, the pack gets locked against repacking. double it and give it to the next one πŸ‘‘
  • --thin β€” fetch a "thin" pack. that means objects are recorded in deltified form based on objects not included in the pack, all to reduce network traffic. efficiency slay 🌈
  • --include-tag β€” if the remote side supports it, annotated tag objects get downloaded on the same connection as the other objects, as long as the object the tag references is also downloaded. Otherwise the caller has to figure out on their own which tags this option made available. iykyk 🧚
  • --upload-pack=<git-upload-pack> β€” use this to specify the path to git-upload-pack on the remote side, if it's not found on your $PATH. like, real scenario: installations of sshd ignore the user's environment setup scripts for login shells (e.g. .bash_profile), and your privately installed git may not be found on the system default $PATH. Another workaround suggested is to set up your $PATH in .bashrc β€” but this flag is for the people who don't wanna pay the overhead for non-interactive shells by having a lean .bashrc file (they set most of the things up in .bash_profile). icons only πŸ’œ
  • --exec=<git-upload-pack> β€” same as --upload-pack=<git-upload-pack>. twin. two names, one vibe πŸ’–
  • --depth=<n> β€” limit fetching to ancestor-chains not longer than n. and heads up: git-upload-pack treats the special depth 2147483647 as infinite, even if there actually is an ancestor-chain that long. iconic number honestly πŸ”₯
  • --shallow-since=<date> β€” deepen or shorten the history of a shallow repository so it includes all reachable commits after <date>.
  • --shallow-exclude=<ref> β€” deepen or shorten the history of a shallow repository to exclude commits reachable from a specified remote branch or tag. and yes, this option can be specified multiple times. stack 'em πŸŽ€
  • --deepen-relative β€” makes the --depth argument specify the number of commits from the current shallow boundary instead of from the tip of each remote branch history. different starting line, same race ✨
  • --refetch β€” skips negotiating commits with the server in order to fetch all matching objects. Use it to reapply a new partial clone blob/tree filter. no small talk, just vibes πŸ’…
  • --no-progress β€” do not show the progress. we go in silence πŸ¦‹
  • --check-self-contained-and-connected β€” outputs "connectivity-ok" if the received pack is self-contained and connected. self-contained AND connected?? we love a well-adjusted pack 🌸
  • -v β€” run verbosely. tell me everything, i'm listening πŸ‘€
  • <repository> β€” the URL to the remote repository. the address, bestie 🏠
  • <refs>... β€” the remote heads to update from. This is relative to $GIT_DIR (e.g. "HEAD", "refs/heads/master"). When unspecified, it updates from all heads the remote side has.

πŸ‘‰ and if the remote has enabled the options uploadpack.allowTipSHA1InWant, uploadpack.allowReachableSHA1InWant, or uploadpack.allowAnySHA1InWant, then they may alternatively be 40-hex sha1s present on the remote. fancy 😌


⭐ SEE ALSO ⭐

  • git-fetch(1) β€” the higher-level wrapper we mentioned. go say hi 🫢

πŸ‘‘ GIT πŸ‘‘

Part of the git(1) suite. one big happy family 🌈


and that's the page, bestie πŸ’– written by the git girlies, Git 2.56.0, dated 2026-09-27 β€” GIT-FETCH-PACK(1), periodt. now go fetch something βœ¨πŸ¦‹

πŸ“¦ where this page comes from