Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> 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.
-
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