Robert Haas wrote:
On Tue, Jun 2, 2009 at 3:58 PM, Andres Freund <and...@anarazel.de> wrote:
#Method 1
cd /../child1
git clone --reference /../master/ git://git.postgresql.org/whatever .
cd /../child2
git clone --reference /../master/ git://git.postgresql.org/whatever .
This way you can fetch from the git url without problem, but when a object
is available locally it is not downloaded again.
Yeah but now you have to push and pull commits between your numerous
local working copies. Boo, hiss.
Why? They are only references. They are effectively local caches. Why
push to them at all?
Push to the central repo. The local copy ("caches") will pick up the
changes eventually. If you really find .git getting larger and this is a
problem (never been a problem for me), "git gc" can keep it to a minimum.
#Method2
cd /../child3
git clone --shared /../postgresql/ child3
...
This way you only fetch from your "pulled" tree and never possibly from the
upstream one.
This is so unsafe it's not even worth talking about. See git-clone(1)
It's not actually unsafe. There are just things to consider.
Particularly, if history is ever removed from /../postgresql/ then the
child3 can become corrupt. There is an easy solution here - don't remove
history from /../postgresql/.
I use the above to save space in a binary-heavy (each workspace is 150
Mbytes+ without --shared) git repo among three designers. It works fine.
We've never had a problem.
That said, I wouldn't recommend it be used unless you do in fact
understand the problem well.
Cheers,
mark
--
Mark Mielke <m...@mielke.cc>
