Re: [PATCH v2] Add --track option to git clone

From: Jeff King <peff@peff.net>
Date: Dec 2, 2009, 22:37 UTC
Message-ID: <20091202223728.GB9691@coredump.intra.peff.net>
In-Reply-To: <20091203060708.6117@nanako3.lavabit.com>

On Thu, Dec 03, 2009 at 06:07:08AM +0900, Nanako Shiraishi wrote:

Show 5 quoted lines

> >   # most general case
> >   git clone -f 'refs/heads/subset/*:refs/remotes/origin/*' remote.git
> 
> Because this is only about branches and no other kinds of 
> references, I think this is an overkill.

Perhaps. I'm not sure this has to be only about branches. You could do:

  git clone -f tags/v1.6.1 git.git

though I admit I don't really have a burning desire to do so. I just think it will be simple to make it flexible (since you have to build such a refspec _anyway_), and there is no reason to restrict people who might use it creatively.

The biggest argument against it would be that we are confusing the user by giving too much rope, but I don't think that is the case here. If you just use branches, you need never know that the full refspec exists (just as some people use "git fetch origin master" without ever understanding how "master" can be replaced by a full refspec).

> >   git clone -f 'subset/*' remote.git
> 
> But I think this is a good idea.

One question on this: does it fetch to "refs/remotes/origin/subset/*" or to "refs/remotes/origin/*"?

I think the latter makes more sense (presumably you don't care that your branches are in "subset/", since you by definition have asked for nothing outside of that namespace).

Show 10 quoted lines

> >   # choose your favorite branch
> >   git clone -f maint -f master -f next -f pu -b next git.git
> > ...
> > What do you think?
> 
> I think your rule to make first branch given by -f the default 
> for -b is a good idea. But I'm not very happy with the example 
> with four -f. Can we probably write it like this?
> 
>   git clone -f maint,master,next,pu git.git

Yeah, that is much nicer. I think "," is allowed in ref names, but I am tempted not to care here. It is not as if this is a low-level feature, and most people will not be crazy enough to use commas in their branch-names. IOW, you will get into trouble only if you have crazy names _and_ you want to use this particular feature. If we wanted to be complete, we could provide a quoting mechanism, but that is perhaps excessive.

> If it isn't a good idea to use comma, we can use colon to split 
> the list of branch names instead.

Colon would work (though of course it would imply not allowing full refspecs with "-f"). However, I actually find

  git clone -f maint:master:next:pu git.git

to be a bit ugly and confusing.

-Peff