On Sun, Jan 26, 2020 at 04:39:52AM -0800, Chris Jerdonek wrote: > However, when I attempted this with a local repo, I found that objects > located only in branches other than the branch I specified are also > cloned. Also, this is true even if the remote repo has only loose > objects (i.e. no pack files). So it doesn't appear to be doing this > only to avoid creating new files. > > In contrast, git-fetch behaves as expected (including locally). > git-fetch appears to fetch only objects in the given branch, when a > branch is specified. This is the expected outcome, because in your example you're cloning on the local filesystem. By default that enables some optimizations, one of which is to hard-link the object files into the destination repository. That avoids the cost of copying and re-hashing them (which a normal cross-system clone would do). And it even avoids traversing the objects to find which are necessary, instead just hard-linking everything. So with: > git clone --branch master --single-branch repo1 repo3 You should be able to see with "git for-each-ref" in repo3 that you only got the "master" branch, but not "dev". But those extra objects are available to you, because of the hard-links. If you do: git clone --branch master --single-branch --no-local repo1 repo4 then repo4 will not have the objects (we really will send a packfile across a pipe, just as we would across the network for a cross-system clone). > cd repo2 > git init > git remote add other file:///<path-to-repo1> > git fetch other master This one behaves as you expected because git-fetch does not perform the same optimizations (it wouldn't make as much sense there, as generally in a fetch we already have most of the objects from the other side anyway, so hard-linking would just give us duplicates). -Peff
