+[ Digression: your GIT "public" repository people can pull from
+ is different from a public CVS repository that lets read-write
+ access to multiple developers. It is a copy of _your_ primary
+ repository published for others to use, and you should not
+ push into it from more than one repository (this means, not
+ just disallowing other developers to push into it, but also
+ you should push into it from a single repository of yours).
+ Sharing the result of work done by multiple people are always
+ done by pulling (i.e. fetching and merging) from public
+ repositories of those people. Typically this is done by the
+ "project lead" person, and the resulting repository is
+ published as the public repository of the "project lead" for
+ everybody to base further changes on. ]
+
+
+ Packing your repository
+ -----------------------
+
+Earlier, we saw that one file under .git/objects/??/ directory
+is stored for each git object you create. This representation
+is convenient and efficient to create atomically and safely, but
+not so 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 .git/objects/pack
+directory.
+
+[ Side 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.
+
+[ Side Note: as we already mentioned, "git pull" is broken for
+ some transports dealing with packed repositories right now, so
+ do not run "git prune-packed" if you plan to give "git pull"
+ access via HTTP transport for now. ]
+
+If you run "git repack" again at this point, it will say
+"Nothing 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
+archive 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 is usually stored
+unpacked in the destination, unless rsync transport is used.
+
+
+ Working with Others
+ -------------------
+
+A recommended work cycle for a "project lead" is like this:
+
+ (1) Prepare your primary repository on your local machine. Your
+ work is done there.
+
+ (2) Prepare a public repository accessible to others.
+
+ (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.
+
+ (5) Keep working in your primary repository, and push your
+ changes to the public repository. Your changes include
+ your own, patches you receive via e-mail, and merge resulting
+ from pulling the "public" repositories of your "subsystem
+ maintainers".
+
+ You can repack this private repository whenever you feel
+ like.
+
+ (6) Every once in a while, "git repack" the public repository.
+ Go back to step (5) and continue working.
+
+A recommended work cycle for a "subsystem maintainer" that
+works on that project and has own "public repository" is like
+this:
+
+ (1) Prepare your work repository, by "git clone" the public
+ repository of the "project lead".
+
+ (2) Prepare a public repository accessible to others.
+
+ (3) Copy over the packed files from "project lead" public
+ repository to your public repository by hand; this part is
+ currently not automated.
+
+ (4) Push into the public repository from your primary
+ repository.
+
+ (5) Keep working in your primary repository, and push your
+ changes to your public repository, and ask your "project
+ lead" to pull from it. Your changes include your own,
+ patches you receive via e-mail, and merge resulting from
+ pulling the "public" repositories of your "project lead"
+ and possibly your "sub-subsystem maintainers".
+
+ You can repack this private repository whenever you feel
+ like.
+
+ (6) Every once in a while, "git repack" the public repository.
+ Go back to step (5) and continue working.
+
+A recommended work cycle for an "individual developer" who does
+not have a "public" repository is somewhat different. It goes
+like this:
+
+ (1) Prepare your work repositories, by "git clone" the public
+ repository of the "project lead" (or "subsystem
+ maintainer", if you work on a subsystem).
+
+ (2) Copy .git/refs/master to .git/refs/upstream.
+
+ (3) Do your work there. Make commits.
+
+ (4) Run "git fetch" from the public repository of your upstream
+ every once in a while. This does only the first half of
+ "git pull" but does not merge. The head of the public
+ repository is stored in .git/FETCH_HEAD. Copy it in
+ .git/refs/heads/upstream.
+
+ (5) Use "git cherry" to see which ones of your patches were
+ accepted, and/or use "git rebase" to port your unmerged
+ changes forward to the updated upstream.
+
+ (6) Use "git format-patch upstream" to prepare patches for
+ e-mail submission to your upstream and send it out.
+ Go back to step (3) and continue.
+
+[Side Note: I think Cogito calls this upstream "origin".
+ Somebody care to confirm or deny? ]
+
+
+[ to be continued.. cvsimports ]