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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 15, 2014, 17:29 UTC
Message-ID: <xmqqwq81w8az.fsf@gitster.dls.corp.google.com>
In-Reply-To: <543E85FA.6050404@xiplink.com>

Marc Branchaud <marcnarc@xiplink.com> writes:

Show 6 quoted lines

> 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.

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.

> 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.