Robert Haas wrote:
> Tom and, I believe, also Andrew have expressed some concerns about the
> space that will be taken up by having multiple copies of the git
> repository on their systems. While most users can probably get by
> with a single repository, committers will likely need one for each
> back-branch that they work with, and we have quite a few of those.
>
> After playing around with this a bit, I've come to the conclusion that
> there are a couple of possible options but they've all got some
> drawbacks.
>
> 1. Clone the origin. Then, clone the clone n times locally. This
> uses hard links, so it saves disk space. But, every time you want to
> pull, you first have to pull to the "main" clone, and then to each of
> the "slave" clones. And same thing when you want to push.
>
>
>
You can have a cron job that does the first pull fairly frequently. It
should be a fairly cheap operation unless the git protocol is dumber
than I think.
The second pull is the equivalent of what we do now with "cvs update".
Given that, you could push commits direct to the authoritative repo and
wait for the cron job to catch up your local base clone.
I think that's the pattern I will probably try to follow.
cheers
andrew
