Re: GIT_OBJECT_DIRECTORY

["Jörn Engel" <joern@wohnheim.fh-wedel.de>]

On Tue, 18 April 2006 11:20:58 -0700, Junio C Hamano wrote:
> Jörn Engel <joern@wohnheim.fh-wedel.de> writes:
> 
> > Well, .git/objects for your kernel still consumes 121M.  It's not
> > gigabytes but I still wouldn't want too many copies of that lying
> > around.
> 
> That is what "git clone -l -s" is for.  

See my response to Linus.  .git/objects is currently the smaller
problem.  The larger problem is 311M of raw kernel source - without
any SCM overhead of any flavour.  Like many others, I solved the
larger problem with hardlink trees.  "git clone -l -s" is imo nearly
unethical, as it solved the smaller problem and leaves the larger one
unaffected.  It reeks of hypocricy.

Hardlink trees still aren't perfect.  If I take one tree, "cp -lr" it
twice and apply the same patches to both copies, the changed files
exist twice for both copies.  That sucks, but it is a fairly small
problem and there is no simple solution to it.

If git was able to deal with hardlink trees and properly break the
links when working in one copy, "cp -lr" would be a lot smarter than
"git clone -l -s".  It just happens that I have written some kernel
patches that automatically break hardlinks, even if applications don't
know how to do it.  So for my personal use, git has this ability.

Now, going one step further, GIT_OBJECT_DIRECTORY could solve another
problem.  Just like source files, git object can be pulled twice into
two copies of a tree.  But for git objects, there appeared to be an
easy solution: the central object storage.  So we're back where this
thread started.

Except that I get the idea of GIT_OBJECT_DIRECTORY not being a simple
solution to a small problem, so maybe I should just forget about it.

Jörn

-- 
To my face you have the audacity to advise me to become a thief - the worst
kind of thief that is conceivable, a thief of spiritual things, a thief of
ideas! It is insufferable, intolerable!
-- M. Binet in Scarabouche