On Tuesday 07 November 2006 14:56, you wrote: > But what happens when an unexperienced user gets this conflict for the > first time (having for the first time used two different remotes)? > Your scheme forces her to learn two new things instead of one, > creating the artificial barrier I mentioned above. I give the user a warning that she has to specify a branch name herself. This does not force her to rename all her branches and go with the new naming <remote>/<remote branch>, but probably makes her do repo developer1, branch next => next (magic behavior) repo developer2, branch next => next2 (manual specification) and perhaps rename next to next1 afterwards. At least I do not want to type long branch names; most of the cloned repos I have do have only one remote. So I would rename the branches names created with the complex magic scheme. Of course, another way is to be more smart with branch name parsing. Currently, a given name is searched in .git/ .git/refs/ .git/refs/tags/ .git/refs/heads/ .git/refs/remotes/ .git/refs/remotes/*/HEAD What about adding before remotes .git/refs/heads/<first-part-of-current-branchname>/ and at the end .git/refs/remotes/<first-part-of-current-branchname>/ Ie. when on branch "origin/next", a given name "master" is parsed as "refs/heads/origin/master" when existing? So the parsing rule is: "With current branch X and given name Y, search for a branch as near as possible to X which has Y as last name component". This would match current UI, where you have simple branch names like "master" or "next". With above rule, you can use "master" to refer to "refs/heads/origin/master" in the complex model, and for a read-only remote head "refs/heads/remotes/origin/next", it is enough to say git-checkout next to get a new local branch "refs/heads/origin/next" created to work on. You keep the simple UI and still get the perfect overview with eg. with "gitk --all" even in the case where you work on 10s of remote branches from multiple repository. Josef - 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