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

From: Marc Branchaud <marcnarc@xiplink.com>
Date: Oct 15, 2014, 20:51 UTC
Message-ID: <543EDE6A.7040500@xiplink.com>
In-Reply-To: <xmqqwq81w8az.fsf@gitster.dls.corp.google.com>

On 14-10-15 01:29 PM, Junio C Hamano wrote:

Show 12 quoted lines

> Marc Branchaud <marcnarc@xiplink.com> writes:
> 
>> I think things would be more understandable if the option was "--dissociate
>> <repository>" and was an explicit alternative to --reference:
>> 	[[--reference | --dissociate] <repository>]
>>
>> I'm still not liking the name "--dissociate" though.  The original suggestion
>> of "--borrow" is better.  Perhaps "--library" or "--local-cache"?  I dunno...
> 
> I was not thinking when I originally started the topic with
> "--borrow", until I realized that it would not make much sense,
> primarily because we allow multiple references.

I hadn't realized that was possible. There's no indication in the man page that multiple --references are allowed (or forbidden, for that matter).

Show 11 quoted lines

> What should this command line do, and how would you implement such a
> behaviour?
> 
>     $ git clone \
>         --reference=/local/pool/linux.git \
>         --borrow=../my/neighbour/linux-hack.git \
>         git://git.kernel.org/...../linux.git
> 
> With "do the usual --reference thing, but then dissociate the result
> from referents" option, there is no ambiguity and that is why I did
> not go with the "--borrow" option suggested in the original thread.

I had not considered this case. My limited imagination has a hard time coming up with a scenario where more than one --reference (or --borrow/--dissociate) would make sense. In this example, the --borrow seems useless. How would clone decide that it even needed objects from the neighbour repo? None of the refs on gko need any of the neighbour's unique objects. (I get the feeling I don't understand how clone works...)

Show 16 quoted lines

>> So now I'm wondering if the implementation would be more efficient as an
>> extension of the --local operation.  That is, instead of a post-clone repack,
>> do a --local clone first followed by a simple "git fetch" from the source repo.
> 
> The network overhead may be comparable to the "--reference"
> optimization, but if your "clone --local" ends up copying (instead
> of hard-linking), the initial cost to copy locally would be a pure
> extra price over "clone --reference and then --dissociate".  If the
> local clone uses hard-linking, it would be cheaper, but it still
> costs more than dropping an entry into .git/objects/info/alternates,
> I would imagine.  You will pay with your scheme the same cost to run
> "repack -a -d", which is paid by "--dissociate" at the end of clone,
> eventually at the first "gc", so there is no efficiency advantage,
> either.
> 
> The above is my knee-jerk assessment without any measuring, though.

That makes sense to me, at least.  I agree with your assessment.

M.