Re: [PATCH 1/2] clone: add disassociate alias to dissociate option

[Michael Haggerty <mhagger@alum.mit.edu>]

On 02/22/2015 07:32 PM, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
> 
>> I wonder if there is some better word that could become a synonym for
>> "--reference --dissociate". Maybe "--borrow", but that does not
>> necessarily carry the implication that the relationship ends as soon as
>> the clone is done.
> 
> You are retracing the exact line of the thinking that led me to a
> cop-out that is a separate "--dissociate".
> 
> The original idea was to give "--borrow /local/repository/path", but
> that would have made it unclear what the differences between that
> new option and existing "--reference" were.  Both borrow the objects
> in order to reduce the network cost, and the difference is that one
> keeps borrowing while the other one limits the borrowing to strictly
> the initial phase.  The two words, "borrow" and "reference", would
> not convey that key distinction.  "Do the reference thing (which is
> well understood from old days, even before v1.6.0) and then severe
> the ties" was suboptimal but was easy to explain, and that is why I
> call it a cop-out.
> 
>> What is really happening is that we are reusing
>> objects in order to save bandwidth. Maybe "--reuse-from" would work?
>>
>> I dunno. I am not extremely happy with any of the suggestions I made,...
> 
> I dunno, either.
> 
> We are all on the same page.  We know the cop-out is suboptimal, we
> understand why the cop-out is better than "--borrow", and we cannot
> come up with a better name that contrasts with the existing
> "--reference" to make it clear how the new thing is different.

I'll take that as an invitation to brainstorm :-)

    --use-objects-from=
    --copy-objects-from=
    --precopy-objects-from=
    --precopy-from=
    --donor=
    --object-donor=
    --steal-from=
    --steal-objects-from=

Of these, I think I like "--object-donor" the best.

By the way, once we have stopped thinking about this feature as
"--reference" and then "--dissociate", it becomes obvious that a nice
generalization would be to allow *any* repository (including remote
ones) to serve as the object donor. This would allow users to get most
of their objects from a "nearby" repository (e.g., a mirror on the LAN)
and then top off from a more distant "authoritative" repository.

In fact, this donor/recipient relationship could be made persistent:
before fetching from repository A, always first fetch any objects that
repository B has available. OTOH, making the relationship persistent
would presumably require us to retain remote-tracking references for
repository B even though they are not intrinsically interesting to the
user, and would lead to reference namespace conflicts if the user wants
a "--mirror" clone.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu