Preparing a Public Repository and Packing Objects

repository to your remote (public) repository requires a write privilege on the remote machine. You need to have an SSH account there to run a single command, 'git-receive-pack'. First, you need to create an empty repository on the remote machine that will house your public repository. This empty repository will be populated and be kept up to date by pushing into it later. Obviously, this repository creation needs to be done only once. [NOTE] 'git push' uses a pair of commands, 'git send-pack' on your local machine, and 'git-receive-pack' on the remote machine. The communication between the two over the network internally uses an SSH connection. Your private repository's Git directory is usually `.git`, but your public repository is often named after the project name, i.e. `<project>.git`. Let's create such a public repository for project `my-git`. After logging into the remote machine, create an empty directory: ------------ $ mkdir my-git.git ------------ Then, make that directory into a Git repository by running 'git init', but this time, since its name is not the usual `.git`, we do things slightly differently: ------------ $ GIT_DIR=my-git.git git init ------------ Make sure this directory is available for others you want your changes to be pulled via the transport of your choice. Also you need to make sure that you have the 'git-receive-pack' program on the `$PATH`. [NOTE] Many installations of sshd do not invoke your shell as the login shell when you directly run programs; what this means is that if your login shell is 'bash', only `.bashrc` is read and not `.bash_profile`. As a workaround, make sure `.bashrc` sets up `$PATH` so that you can run 'git-receive-pack' program. [NOTE] If you plan to publish this repository to be accessed over http, you should do `mv my-git.git/hooks/post-update.sample my-git.git/hooks/post-update` at this point. This makes sure that every time you push into this repository, `git update-server-info` is run. Your "public repository" is now ready to accept your changes. Come back to the machine you have your private repository. From there, run this command: ------------ $ git push <public-host>:/path/to/my-git.git master ------------ This synchronizes your public repository to match the named branch head (i.e. `master` in this case) and objects reachable from them in your current repository. As a real example, this is how I update my public Git repository. Kernel.org mirror network takes care of the propagation to other publicly visible machines: ------------ $ git push master.kernel.org:/pub/scm/git/git.git/ ------------ Packing your repository ----------------------- Earlier, we saw that one file under `.git/objects/??/` directory is stored for each Git object you create. This representation is efficient to create atomically and safely, but not so convenient to transport over the network. Since Git objects are immutable once they are created, there is a way to optimize the storage by "packing 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. ------------ $

This section explains how to create a public Git repository, make it available for others to pull from, and set up the necessary configuration, including running 'git init' and 'git-receive-pack', and making the repository accessible over http if needed, and then discusses packing Git objects together for more efficient storage and transportation using 'git repack' and verifying the integrity of the packs with 'git verify-pack'.