On 02/22/2015 07:32 PM, Junio C Hamano wrote:
> Jeff King <p...@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
mhag...@alum.mit.edu
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
