Re: [PATCH] add --remote option to git-clone.

[Junio C Hamano <junkio@cox.net>]

Jakub Narebski <jnareb@gmail.com> writes:

>> I did not find anything MS'esque in what MST did in his patch,
>> though.  I think it is a reasonable thing to ask for from a
>> clone.  For example, if you are coming from CVS or have used
>> Cogito, cloning a single branch is not an unusual operation at
>> all.
>
> But when we clone whole repository we could have download whole
> object database of cloned repo as-is (perhaps packing loose objects
> in smart/git-aware transports).

I think your point is if you have branches A and B, cloning A+B
as a whole is a lot less expensive than cloning A and then B
separately.  While that is true, I do not think that reasoning
would apply to somebody, especially behind a slow link, who is
only interested in A.  She does not want to pay the cost of A+B,
when she only wants A, even if A+B is much less expensive than
twice the cost of getting A.

Also, if she later gets interested in B, git fetch will make the
"what's common" optimization.  It won't be like cloning A and
then fetching B into the same repository later would be twice as
expensive compared to the case where you start from a clone as a
whole.  The overall transfer cost would probably be comparable.

> By the way, there was discussed idea about marking pu-like branches
> as being rewound (non-fast forwarding) in the config file, and somehow
> transferring this information for git-clone for it to have '+' for
> some refspecs. What happened to that idea? Was it abandoned...

Well, I would not call some idle talk without a concrete design
(preferably with a proof-of-concept code, but that is not an
absolute requirement) "idea".  Something that did not even start
cannot get abandoned ;-).

I thought that it would not hurt to have something like that,
but because in 1.5.0 "git clone" creates fetch configuration of
'forcing' kind by default, I do not think it makes that much of
a difference.