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

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

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Oh? Well, to me, "clone" meant something like the genetics thing, i.e. get 
> a copy of the repository. Since a "branch" is not the complete repository, 
> but only part of it, I would have expected "engraft" instead of "clone" 
> there.
>
> But I can learn! So (post-1.5.0, maybe?) I'd be perfectly d'accord with 
> something like this
>
> 	git clone git://.../git.git#html
>
> to mean "just fetch the branch html, and check it out".

I agree that the word "clone" to me sounds like "copy the whole
repo", so a single branch cloning feels it is something
different from "clone", but I do not think it means wholeness
must be the only mode of operation.

Except that I do not particularly think the URL fragment
notation is such a "cool" syntax.

>> I think the logic to decide where to point remotes/$origin/HEAD to 
>> should be moved to "git-remote add -m" when we eventually rewrite 
>> "git-clone" to use "git-remote add -f".  And while we would do so, we 
>> can make a trivial extension to fetch-pack protocol to carry the HEAD 
>> symref information.  All will be good once that happens.
>
> Would you like this as a multi_ack-like extension?
>
> But then how to teach the dumb protocols in a backwards-compatible 
> fashion?

I am not talking about enhancing ls-remote output nor info/refs
file format.  I do not think we need to do anything special to
support it in backwards compatible way.

Look at what dumb protocols do in git-clone.  http already knows
where HEAD points at when it fetches HEAD with curl.  I do not
particularly care about rsync, but I suspect it can be handled
the same way.