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

From: Karl Hasselström <kha@treskal.com>
Date: Nov 7, 2006, 13:56 UTC
Message-ID: <20061107135609.GA32376@diana.vm.bytemark.co.uk>
In-Reply-To: <200611071153.32840.Josef.Weidendorfer@gmx.de>

On 2006-11-07 11:53:32 +0100, Josef Weidendorfer wrote:

Show 11 quoted lines

> On Tuesday 07 November 2006 07:54, you wrote:
>
> > Having more than one local branch for a remote branch is advanced
> > enough that the user should know how to create branches with any
> > name they choose.
>
> But such an advanced szenario is exactly the reason to introduce
> these long branch names like "origin/next", isn't it? When a newbie
> probably never is confronted with this szenario, then why give him
> longer branch names per default? Do you see the contradiction in
> this argument?

Well, I see your point. However, forcing users to have to unlearn and relearn when they want to use more of git's power feels wrong. It would present an artificial barrier for users wishing to proceed from the newbie stage.

It's more important to have simple rules than to make these rules generate short names. Long names are not conceptually difficult, just a bit cumbersome at times.

> IMHO it should be the other way around: when an advanced user gets
> this conflict, he knows how to rename the branches by using this
> more elaborated scheme.

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.

-- 
Karl Hasselström, kha@treskal.com