On Wed, Jul 21, 2010 at 9:22 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On the other hand, if you have technical corrections, or if
> you have suggestions on how to do the same things better (rather than
> suggestions on what to do differently), that would be greatly
> appreciated.
Somewhere in that wiki page there is some musing about the size of
.git directories being somewhat dissatisfying when one feels compelled
to have multiple check-outs materialized.
There's a facility in git known as "alternates" that let you fetch
objects from some other pool. This is highly useful if you have the
same project checked out many times, either for personal use or on a
hosting server of some sort.
Because the object pool being referenced has no knowledge of other
repositories referencing it, garbage collection (should you be doing
things that generate garbage, such deleting branches and tags) of the
underlying pool can cause corruption in referencing repositories in
the case where they reference objects that have since been deleted.
This will never happen if the repository monotonically grows, as is
often the case for a 'authoritative' repository, such as the one at
git.postgresql.org that only has major branches and release tags that
will never go away. (save the rare case when fixing up after a cvs
race condition that has occurred a few times in the past).
In practice, one can just make a clean clone of a project for the
purposes of such an object pool and then let it sit for months or even
years, as the size of each subsequent .git, even for considerable
amounts of history, is marginal. Once in a while one can perform the
clean-up task of catching up the object pool, if they feel their .git
directories have gotten unacceptably large.
Here's a brief section about it on a git wiki:
https://git.wiki.kernel.org/index.php/GitFaq#How_to_share_objects_between_existing_repositories.3F
fdr
