On Thu, Dec 21, 2006 at 03:01:21PM -0800, Junio C Hamano wrote: > > $ git checkout -b local_next origin/next > > "git checkout -b next origin/next" should work just fine, I > think. > > There was a talk about allowing "checkout -b <new> <track>" to > add branch.<new>.merge and branch.<new>.remote if <track> can be > proven to corresond uniquely to one remote and one branch from > that remote; I think that would match the expectation most of > the time but that "most" would not be 100% nor even 80%, so I > think that should be an optional feature. In any case, there > was a talk but there is no code yet. BTW, is there some explanation why branch.*.merge specifies a _remote_ head? The following would make much more sense to me: [branch "master"] remote = origin merge = refs/remotes/origin/master Because I don't _care_ that the other guy calls it refs/heads/master. I care that I'm pulling from refs/remotes/origin/master on my end (and however I get stuff into that branch is defined by the remote). It also means that even without a remote, the merge option makes sense (e.g., if I do repeated merges from one local branch to another). And it means that it's _always_ correct for "checkout -b <new> <track>" to set branch.<new>.merge to <track>, without having to worry about finding an appropriate remote. -Peff - 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