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 -- 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
