Re: [PATCH/RFC] Convenient support of remote branches in git-checkout

From: Josef Weidendorfer <josef.weidendorfer@gmx.de>
Date: Nov 7, 2006, 17:04 UTC
Message-ID: <200611071804.43724.Josef.Weidendorfer@gmx.de>
In-Reply-To: <20061107135609.GA32376@diana.vm.bytemark.co.uk>

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.