Re: git clone does not work with GIT_OBJECT_DIRECTORY set

Benjamin LaHaise [off-list ref] writes:

On Sun, Mar 05, 2006 at 05:33:25PM -0800, Junio C Hamano wrote:

quoted

Please try it without GIT_OBJECT_DIRECTORY and see it works
correctly (I think it should).  If that is the case, maybe
git-clone should explicitly unset GIT_OBJECT_DIRECTORY.

Nope.  There is no .git/objects directory, so how would it be able to 
find the objects?

Ah, I misunderstood what you were trying to do here.  What you
meant with this is:

	$ git clone linux-2.6.git bootcache.git

* linux-2.6.git is a local directory with HEAD, refs/* and stuff
  but does not have objects/.

* bootcache.git is a local directory to be created anew.

Even though linux-2.6.git does not have objects subdirectory, it
is usually not a problem for you because you use GIT_OBJECT_DIRECTORY
for that.

Short answer for this is: sorry, "git clone" barebone Porcelain
does not support such a configuration if your source repository
is local.  It works for destination, though:

	$ export GIT_OBJECT_DIRECTORY=/tmp/foobla 
	$ git clone git://git.kernel.org/.../linux-2.6.git bootcache.git

You will get a single pack in /tmp/foobla/pack and would not
even have bootcache.git/.git/objects directory.

I should probably add that GIT_OBJECT_DIRECTORY environment
variable has outlived its usefulness.  Initially we added that
flexibility without really knowing where it would lead us, but
it has turned out that often we would want the refs and objects
go hand-in-hand.  Two or more repositories sharing the object
pool to save storage initially sounded a good idea, but that
would make fsck-objects cumbersome (you have to learn to ignore
dangling warnings, which makes checking rather pointless), and
packing less useful (you need to collect refs in all the
repositories that share the object pool).

I think the recommended way these days to set up multiple
repositories that work on related projects is to set up a single
clone from external source (e.g. linux-2.6.git), and make a set
of local "-l -s" clones out of it, and then fetch forked
upstreams into them.  It would go something like this:

(initial setup)
	$ git clone --bare git://git.kernel.org/.../torvalds/linux-2.6.git \
          linux-2.6.git

    (do this only once for each forked upstream)
        $ git clone -l -s -n linux-2.6.git netdev-2.6
	$ cd netdev-2.6
        $ ed .git/remotes/origin ;# adjust to jgarzik tree's location
        $ mkdir .git/refs/stashed
        $ mv .git/refs/heads .git/refs/tags .git/refs/stashed
        $ mkdir .git/refs/heads .git/refs/tags
	$ git fetch -k 
        $ cp .git/refs/heads/origin .git/refs/heads/master
        $ rm -fr .git/refs/stashed
        $ git checkout
        
(update the shared master tree from time to time)
	$ cd linux-2.6.git
        $ GIT_DIR=. git fetch-pack \
          git://git.kernel.org/.../torvalds/linux-2.6.git

(working in the individual forked tree is just as usual)
	$ cd netdev-2.6
        $ git fetch ;# or git pull

I think the part for each forked upstream above that consists of
10 or so commands above can be more or less automated.  The part
that needs human input is the adjusting of .git/remotes/origin,
which depends on where each forked upstream tree is and what
branches there are of interest.

On Mon, Mar 06, 2006 at 10:29:51PM -0800, Junio C Hamano wrote:

I think the recommended way these days to set up multiple
repositories that work on related projects is to set up a single
clone from external source (e.g. linux-2.6.git), and make a set
of local "-l -s" clones out of it, and then fetch forked
upstreams into them.  It would go something like this:

I had been doing that, but it's gotten too painful to keep everything in 
sync.  Sigh.

		-ben
-- 
"Time is of no importance, Mr. President, only life is important."
Don't Email: [off-list ref].