git clone ignores GIT_ALTERNATE_OBJECT_DIRECTORIES

git clone ignores GIT_ALTERNATE_OBJECT_DIRECTORIES

[Brian Ristuccia]

When running git clone, it seems that GIT_ALTERNATE_OBJECT_DIRECTORIES is
not considered. Even though most of the needed objects are in
GIT_ALTERNATE_OBJECT_DIRECTORIES, I still wind up with a ton of traffic over
the network and a huge .git/objects hierarchy.

Running "git gc" later pares down the .git/objects to a more reasonable
size, so it seems the problem is limited to git clone. Using "git clone
--reference" also seems to do the right thing.

Is this behavior intentional for some good reason I've overlooked, or have I
stumbled on a bug?

-- 
Brian Ristuccia
brian@ristuccia.com

Re: git clone ignores GIT_ALTERNATE_OBJECT_DIRECTORIES

[Junio C Hamano]

Brian Ristuccia <brian@ristuccia.com> writes:

> Is this behavior intentional for some good reason I've overlooked, or have I
> stumbled on a bug?

Most likely not a bug.

When you talk about "clone", you need to realize that there actually are
two repositories (and two object databases) involved: cloned source and
destination.

Which repository should GIT_ALTERNATE_OBJECT_DIRECTORIES affect?

If you are making a clone from a remote over the network, and if you
already have another local repository of a related project that has
necessary objects, you may want to look at

    "git clone --reference"

Re: git clone ignores GIT_ALTERNATE_OBJECT_DIRECTORIES

[Brian Ristuccia]

On Thu, Jul 30, 2009 at 01:04:31PM -0700, Junio C Hamano wrote:
> Brian Ristuccia <brian@ristuccia.com> writes:
> 
> > Is this behavior intentional for some good reason I've overlooked, or have I
> > stumbled on a bug?
> 
> Most likely not a bug.
> 
> When you talk about "clone", you need to realize that there actually are
> two repositories (and two object databases) involved: cloned source and
> destination.
> 
> Which repository should GIT_ALTERNATE_OBJECT_DIRECTORIES affect?
> 

Whichever one git is currently working in. (Even if git picks the "wrong"
repository, object f1d2d2f924e986ac86fdf7b36c94bcdf32beec15 is still
f1d2d2f924e986ac86fdf7b36c94bcdf32beec15 regardless of which repo it appears
in and the end result will be consistent). 

My understanding after reading gitrepository-layout(5), git-fsck(1),  is
that the effect of listing a directory in GIT_ALTERNATE_OBJECT_DIRECTORIES
should be roughly the same as listing it in the .git/objects/info/alternates
of whatever repository git happens to be working on.
   
> If you are making a clone from a remote over the network, and if you
> already have another local repository of a related project that has
> necessary objects, you may want to look at
> 
>     "git clone --reference"
> 

Yes, this does the right thing as I mentioned in my previous message.
(Behind the scenes, it's setting up .git/objects/info/alternates). My
question is why doesn't GIT_ALTERNATE_OBJECT_DIRECTORIES behave the same as
.git/objects/info/alternatives in all cases?

-- 
Brian Ristuccia
brian@ristuccia.com