Josef Weidendorfer <Josef.Weidendorfer@xxxxxx> wrote: > On Saturday 04 November 2006 06:03, Shawn Pearce wrote: > > After reading your reply you are probably correct. I can see there > > may be workflows that want every remote branch also created as a > > local branch. > > > > I could certainly live with a command line option to clone, e.g.: > > > > git clone --only vmdvt,vmtip user@host:/path... > > Still missing here: What branch should be checked out after > cloning? Ah. I probably should have also stated that my users should be doing -n as well with git clone, then using git checkout -b to create a new branch from one of the refs they did clone. (Reason is we strictly follow a topic branch model of development, with even the developer's local branches beginning with their initials.) But you have a good point. Cloning with say --only as I show above might be confusing as its not defined what branch to checkout after the clone. > Perhaps it is better to extend git-checkout to allow to do the > correct thing when the user specifies a read-only branch from > refs/remotes. E.g. with refs/remotes/origin/vmdvt, > > git checkout origin/vmdvt > > should create a new local branch refs/heads/vmdvt which forks > from remotes/origin/vmdvt (and abort with > error if refs/heads/vmdvt already exists without being the local > development branch for remotes/origin/vmdvt) Yes, that would work for our workflow. I won't try to speak about anyone else's. I'd also say that if the local branch (refs/heads/vmdvt) exists and if `git pull . origin/vmdvt` is going to be a fast-forward that the fast-forward should happen during the checkout. That way after the checkout is complete you really do have what is in origin/vmdvt, but are sitting on a local branch. -- Shawn. - 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