Packing Objects and Working with Others

them together". The command ------------ $ git repack ------------ will do it for you. If you followed the tutorial examples, you would have accumulated about 17 objects in `.git/objects/??/` directories by now. 'git repack' tells you how many objects it packed, and stores the packed file in the `.git/objects/pack` directory. [NOTE] You will see two files, `pack-*.pack` and `pack-*.idx`, in `.git/objects/pack` directory. They are closely related to each other, and if you ever copy them by hand to a different repository for whatever reason, you should make sure you copy them together. The former holds all the data from the objects in the pack, and the latter holds the index for random access. If you are paranoid, running 'git verify-pack' command would detect if you have a corrupt pack, but do not worry too much. Our programs are always perfect ;-). Once you have packed objects, you do not need to leave the unpacked objects that are contained in the pack file anymore. ------------ $ git prune-packed ------------ would remove them for you. You can try running `find .git/objects -type f` before and after you run `git prune-packed` if you are curious. Also `git count-objects` would tell you how many unpacked objects are in your repository and how much space they are consuming. [NOTE] `git pull` is slightly cumbersome for HTTP transport, as a packed repository may contain relatively few objects in a relatively large pack. If you expect many HTTP pulls from your public repository you might want to repack & prune often, or never. If you run `git repack` again at this point, it will say "Nothing new to pack.". Once you continue your development and accumulate the changes, running `git repack` again will create a new pack, that contains objects created since you packed your repository the last time. We recommend that you pack your project soon after the initial import (unless you are starting your project from scratch), and then run `git repack` every once in a while, depending on how active your project is. When a repository is synchronized via `git push` and `git pull` objects packed in the source repository are usually stored unpacked in the destination. While this allows you to use different packing strategies on both ends, it also means you may need to repack both repositories every once in a while. Working with Others ------------------- Although Git is a truly distributed system, it is often convenient to organize your project with an informal hierarchy of developers. Linux kernel development is run this way. There is a nice illustration (page 17, "Merges to Mainline") in https://web.archive.org/web/20120915203609/http://www.xenotime.net/linux/mentor/linux-mentoring-2006.pdf[Randy Dunlap's presentation]. It should be stressed that this hierarchy is purely *informal*. There is nothing fundamental in Git that enforces the "chain of patch flow" this hierarchy implies. You do not have to pull from only one remote repository. A recommended workflow for a "project lead" goes like this: 1. Prepare your primary repository on your local machine. Your work is done there. 2. Prepare a public repository accessible to others. + If other people are pulling from your repository over dumb transport protocols (HTTP), you need to keep this repository 'dumb transport friendly'. After `git init`, `$GIT_DIR/hooks/post-update.sample` copied from the standard templates would contain a call to 'git update-server-info' but you need to manually enable the hook with `mv post-update.sample post-update`. This makes sure 'git update-server-info' keeps the necessary files up to date. 3. Push into the public repository from your primary repository. 4. 'git repack' the public repository. This establishes a big pack that contains the initial set of objects as the baseline, and possibly 'git prune' if the transport used for pulling from your repository supports packed repositories. 5. Keep working in your primary repository.

This section discusses packing Git objects together for efficient storage, using 'git repack' and 'git prune-packed' to remove unnecessary unpacked objects, and then covers strategies for working with others on a Git project, including organizing an informal hierarchy of developers, preparing a public repository, and establishing a workflow for project leads to manage their primary and public repositories.