From: Junio C Hamano <gitster@pobox.com>
To: Marc Branchaud <marcnarc@xiplink.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] clone: --dissociate option to mark that reference is only temporary
Date: Wed, 15 Oct 2014 10:29:24 -0700 [thread overview]
Message-ID: <xmqqwq81w8az.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <543E85FA.6050404@xiplink.com> (Marc Branchaud's message of "Wed, 15 Oct 2014 10:34:34 -0400")
Marc Branchaud <marcnarc@xiplink.com> writes:
> 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.
next prev parent reply other threads:[~2014-10-15 17:29 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-14 19:57 [PATCH] clone: --dissociate option to mark that reference is only temporary Junio C Hamano
2014-10-15 14:34 ` Marc Branchaud
2014-10-15 17:29 ` Junio C Hamano [this message]
2014-10-15 20:51 ` Marc Branchaud
2014-10-15 21:33 ` Junio C Hamano
2014-10-15 21:44 ` Marc Branchaud
2014-10-15 21:50 ` Junio C Hamano
2014-10-16 15:26 ` Marc Branchaud
2014-10-17 12:47 ` Jakub Narębski
2014-10-16 19:27 ` Junio C Hamano
2014-10-15 19:44 ` Johannes Sixt
2014-10-15 21:33 ` Junio C Hamano
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=xmqqwq81w8az.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=marcnarc@xiplink.com \
/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.