Re: [PATCH] clone: --dissociate option to mark that reference is only temporary

[Marc Branchaud <marcnarc@xiplink.com>]

On 14-10-15 05:50 PM, Junio C Hamano wrote:
> Marc Branchaud <marcnarc@xiplink.com> 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.