On Sat, Jan 31, 2009 at 12:12 AM, Jeff King <peff@xxxxxxxx> wrote: > but presumably in your example the second clone is _not_ on the NFS > mount, and therefore can't hardlink. That's correct. > So you can try "git clone -s" to specify that you definitely want > alternates. Well, the clone gets the alternates either way. It just doesn't use them to avoid copying the data unless I give -s. More importantly, if 'git clone' worked the way I thought, then when I clone a remote repository for which I have a local mirror, I could avoid typing '--reference <path to local mirror>' by adding <path to local mirror>/objects to the alternates file in the remote repository. > 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)? Damn. I was hoping the response would be "it's a regression, and here's a patch to fix it". I went ahead and tested a few old versions and they all behave the same way. So, is there any reason 'git clone' shouldn't automatically use the alternates that it copied into the new repository? I might look into writing a patch if nobody objects. James -- 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
