Re: [PATCH] clone: --dissociate option to mark that reference is only temporary

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Marc Branchaud <marcnarc@xxxxxxxxxxx> 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.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]