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

From: Junio C Hamano <junkio@cox.net>
Date: Feb 5, 2007, 17:58 UTC
Message-ID: <7vmz3smqpp.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.63.0702051245050.22628@wbgn013.biozentrum.uni-wuerzburg.de>

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

Show 11 quoted lines

> 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.

Show 10 quoted lines

>> 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.