Skip to content

Instantly share code, notes, and snippets.

@ugultopu

ugultopu/Just like packed objects, Git also has "packed refs".md

Last active February 22, 2021 16:10
Show Gist options
  • Save ugultopu/30ce87411bf3c13c3121b52134afc034 to your computer and use it in GitHub Desktop.
Save ugultopu/30ce87411bf3c13c3121b52134afc034 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
Just like packed objects, Git also has "packed refs".md

Hence, if you cannot find a ref under .git/refs directory, it is probably in the .git/packed-refs file, which is a commit to ref mapping.

Here is a good description of what "packed refs" in Git are, taken from that manual of git-pack-refs command:

Traditionally, tips of branches and tags (collectively known as refs) were stored one file per ref in a (sub)directory under $GIT_DIR/refs directory. While many branch tips tend to be updated often, most tags and some branch tips are never updated. When a repository has hundreds or thousands of tags, this one-file-per-ref format both wastes storage and hurts performance.

This command is used to solve the storage and performance problem by storing the refs in a single file, $GIT_DIR/packed-refs. When a ref is missing from the traditional $GIT_DIR/refs directory hierarchy, it is looked up in this file and used if found.

Subsequent updates to branches always create new files under $GIT_DIR/refs directory hierarchy.

A recommended practice to deal with a repository with too many refs is to pack its refs with --all once, and occasionally run git pack-refs. Tags are by definition stationary and are not expected to change. Branch heads will be packed with the initial pack-refs --all, but only the currently active branch heads will become unpacked, and the next pack-refs (without --all) will leave them unpacked.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment