On 14-10-15 05:50 PM, Junio C Hamano wrote: > Marc Branchaud <marcnarc@xxxxxxxxxxx> writes: > >> Yes, but we're cloning gko, not the neighbour. Doesn't that mean that the >> clone operation won't know about any of the neighbour's refs? > > No. --reference (and a natural implementation of --borrow, I would imagine) > peeks the refs of the repository we borrow from and that is how > clone can say "I already have objects reachable from these refs, so > please send me the remainder" to the repository it is cloning from. By "know about" I meant "want to use". Sorry for being a bit dense about this; let me try again. (BTW, it occurs to me that your patch -- if I read it right -- doesn't fulfill your scenario since it disassociates the clone from all repos, regardless of whether they are specified with --reference or --borrow. In the following I assume a --borrow that only disassociates from the specified repo and leaves the --reference repo(s) alone.) Since we're cloning gko's refs, all of the neighbour's unique refs and objects can be ignored. Even though paths to the neighbour and the local pool will be in the clone's alternates file, any refs the clone operation creates won't need to use any objects from the neighbour. The clone operation gives us no way to refer to the neighbour's unique objects. I just don't see what difference the --borrow option makes. Consider the two cases: With just --reference=/local/pool/linux.git: 1. Set up the alternates file with that path. 2. Copy gko's refs into refs/remotes/origin/. 3. Set up refs/heads/master to refer to gko's HEAD. 4. Checkout refs/heads/master (uses objects from local pool). With both that --reference and --borrow=../my/neighbour/linux-hack.git: 1. Set up the alternates file with both paths. 2. Copy gko's refs into refs/remotes/origin/. 3. Set up refs/heads/master to refer to gko's HEAD. 4. Checkout refs/heads/master (uses objects from local pool). 5. Disassociate ourselves from the neighbour repo. In both cases the first four actions have no need of the neighbour repo. The second case's fifth action surgically removes the neighbour as an alternate object store, and we're left with the same clone we got in the first case. What was the point? It seems that in order to make something like --borrow useful, "git clone" would somehow need to know which of the neighbour's refs you want to *also* clone, then copy any unique objects from the neighbour before disassociating from it. M. -- 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