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

From: Junio C Hamano <junkio@cox.net>
Date: Feb 3, 2007, 03:00 UTC
Message-ID: <7vmz3wdjxu.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.63.0702021146440.22628@wbgn013.biozentrum.uni-wuerzburg.de>

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

Show 10 quoted lines

> On Thu, 1 Feb 2007, Junio C Hamano wrote:
> ...
>> I am not against the general idea of tracking a subset of
>> branches, but issues include:
>>
>> [explains why git-remote is a better place for this]
>
> Seeing your patch to git-remote, it feels more natural, too. Especially 
> since that (or which? :-D) does not give the term "clone" a 
> Microsoft'esque completely new meaning.

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.

The real point of my 'remote add -f -t -m' patch is that I think we are much better off to do it in a bottom up way, by having a tool that can be used in any repository first. Then we could even rewrite 'git clone' along these lines:

	#/bin/sh
	track="*" ;# command line parameter to override...
	... decide what $name to use ...
	mkdir "$name"
	cd "$name"
	git init-db
        git remote add -f -t "$track" origin $url
	git branch -f master remotes/origin/master

Of course you would need to deal with -n, --bare and stuff, but that is a minor detail.

While I am talking about post 1.5.0 git-clone changes, one thing I've always hated about git-clone is that the cloner always has to guess where the HEAD pointer at the other side points at. This comes from a shortcoming in the fetch-pack protocol (it simply does not tell). A stupid consequence of this is that cloning over dumb protocols also have to guess, although they are _capable_ of letting the cloner know this information.

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.