On Tue, Jan 28, 2020 at 05:59:54PM -0800, Chris Jerdonek wrote: > > No, "--reference" behaves as usual. > > On this, I found that --reference does behave differently in the way > that I suspected. For example, when run with the default --local, I > found that git-clone will create hard links in the new repo to loose > objects, even if those objects already exist in the reference > repository. When run with --non-local, the objects in the reference > repository weren't copied (I didn't find them in the cloned repo's > pack file). Sure, but I'd just consider that the same issue: hardlinking takes everything in the object database without regard to what's needed. So --reference still works (and when you repack and break the hardlinks, it will drop any duplicates as usual), but obviously you have access to the extra hardlinked objects in the meantime. IOW, I don't think it's worth calling this out in the --reference documentation, but could be in the --local documentation. Because the unusual implication is the same whether --reference is used or not. > So in addition to --single-branch, this seems to be another case where > `git-clone --local` will ignore the provided options when deciding > what files inside .git/objects/ to hard-link. It just hard-links > everything. This is another example of something that I think would be > worth mentioning in the docs in some form. Currently, the > documentation for --reference suggests that objects won't be created > in the new repo if they already exist in the reference repository. It says: Using an already existing repository as an alternate will require fewer objects to be copied from the repository being cloned, reducing network and local storage costs. which I think is still technically true. The hardlinks are free in terms of storage (and there's no network cost by definition). So at worst --reference is doing nothing to start with. And the repository has been setup in such a way that it may yield benefits later (after you repack and the hardlinks are broken). This is maybe splitting hairs a bit. The thing that matters, I think, is where a documentation change should go (and what it should say). -Peff
