Hi,

On Fri, 2 Feb 2007, Junio C Hamano wrote:

quoted text
> Johannes Schindelin <Johannes.Schindelin@gmx.de> 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.

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

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

Yeah, that makes sense.

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

Would you like this as a multi_ack-like extension?

But then how to teach the dumb protocols in a backwards-compatible 
fashion?

Ciao,
Dscho

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html