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$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=marcnarc@xiplink$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox