From: Jeff King Date: Sat, 31 Jan 2009 07:12:38 GMT Subject: Re: 'git clone' doesn't use alternates automatically? Message-ID: <20090131071238.GC3033@coredump.intra.peff.net> In-Reply-To: <885649360901301412jd5c6b0dne1eff1ff00dd043e@mail.gmail.com> On Fri, Jan 30, 2009 at 03:12:42PM -0700, James Pickens wrote: > I have a central, shared Git repository on an NFS drive at path > $central. I have added "$central/objects" to > $central/objects/info/alternates. I see that when I clone this > repository with Git 1.6.1, the alternates file is automatically copied > to the clone, but so are all the pack files and loose objects. If I > then cd to the clone and run 'git gc', it removes the redundant local > objects. Yes, we don't set up alternates to an origin by default. If it's a local clone, we do hardlink by default: $ ls -i git/.git/objects/pack 7639155 pack-0651ae7e35ffde1921db158a3292e1c81153be1a.idx 7638782 pack-0651ae7e35ffde1921db158a3292e1c81153be1a.pack $ git clone git foo ... $ ls -i foo/.git/objects/pack 7639155 pack-0651ae7e35ffde1921db158a3292e1c81153be1a.idx 7638782 pack-0651ae7e35ffde1921db158a3292e1c81153be1a.pack but presumably in your example the second clone is _not_ on the NFS mount, and therefore can't hardlink. So you can try "git clone -s" to specify that you definitely want alternates. > I thought I tested this setup a few months back, and 'git clone' > automatically used the alternates file to avoid copying the redundant > objects into the clone. Has this behavior changed, or is my memory > bad? I don't recall clone ever being that clever, but I could be wrong (it is not an area of the code that I am too familiar with). Can you try a test with a few different versions to see if it ever behaved as you expected (and if it does, bisect to find the breakage)? -Peff