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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 15, 2014, 21:33 UTC
Message-ID: <xmqqsiipuifi.fsf@gitster.dls.corp.google.com>
In-Reply-To: <543EDE6A.7040500@xiplink.com>

Marc Branchaud <marcnarc@xiplink.com> writes:

Show 17 quoted lines

> On 14-10-15 01:29 PM, Junio C Hamano wrote:
>
>>     $ 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
> 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.

A probable scenario might go like this.

    The company-wide pool is designed for everybody's use and will
    stay, even if it lags behind because it fetches every other day,
    so it is safe to keep referring to via alternates.  My neighbour
    is following the linux-next repository and has changes that are
    meant to land "in the future" to the mainline, but it can
    disappear without notice so I cannot afford to depend on its
    presense forever.

Under that particular scenario, what should happen is fairly clear; we want to dissociate from neibour's immediately after clone is done, while being still dependent on the shared pool. But there is the question of "how would you implement such a behaviour" (even if you know that is the single only behaviour you would want to see).

Also I am not confident enough that it is the only plausible way any user may want to mix reference and borrow together.