Hi, On Fri, 2 Feb 2007, Junio C Hamano wrote: > 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. 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". > 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. > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html