On Thu, Jul 30, 2009 at 01:04:31PM -0700, Junio C Hamano wrote: > Brian Ristuccia <brian@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html