From: Junio C Hamano <gitster@pobox.com>
To: Michael Haggerty <mhagger@alum.mit.edu>
Cc: Jeff King <peff@peff.net>, Matt Whiteley <mattwhiteley@gmail.com>,
git@vger.kernel.org
Subject: Re: [PATCH 1/2] clone: add disassociate alias to dissociate option
Date: Tue, 24 Feb 2015 12:06:31 -0800 [thread overview]
Message-ID: <xmqqbnkjqdko.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <54EC3EF8.7040302@alum.mit.edu> (Michael Haggerty's message of "Tue, 24 Feb 2015 10:06:00 +0100")
Michael Haggerty <mhagger@alum.mit.edu> writes:
> On 02/22/2015 07:32 PM, Junio C Hamano wrote:
>> ... 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. ... and that is why I
>> call it a cop-out.
>> ...
>> 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.
Donor (somehow the word reminds me of organ harvesting, yuck)?
I didn't think of the word 'copy', but that probably captures the
essence the best. "reference-to-borrow-and-then-dissociate" is an
implementation detail, which, as you say, we do not want the users
to view this operation as; copying locally instead of over the
network is what the user wants to do.
> 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.
As I do not think of a workable approach to implement such a
mechanism, I'd refrain from being irresponsible and say "Yeah,
that's a neat idea", which would make me sound like clueless "me
too, why doesn't Git do that?" crowd.
next prev parent reply other threads:[~2015-02-24 20:06 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-20 19:10 [PATCH] --disassociate alias for --dissociate clone option Matt Whiteley
2015-02-20 19:10 ` [PATCH 1/2] clone: add disassociate alias to dissociate option Matt Whiteley
2015-02-21 6:27 ` Jeff King
2015-02-21 7:13 ` Junio C Hamano
2015-02-21 7:35 ` Jeff King
2015-02-22 18:32 ` Junio C Hamano
2015-02-24 9:06 ` Michael Haggerty
2015-02-24 20:06 ` Junio C Hamano [this message]
2015-02-24 22:00 ` Michael Haggerty
2015-02-20 19:10 ` [PATCH 2/2] clone: Realign lines near disassociate option Matt Whiteley
2015-02-20 22:01 ` [PATCH] --disassociate alias for --dissociate clone option Eric Sunshine
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqbnkjqdko.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=mattwhiteley@gmail.com \
--cc=mhagger@alum.mit.edu \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.