On Thu, 30 Oct 2008, Sam Vilain wrote:
> On Thu, 2008-10-30 at 12:53 -0400, Nicolas Pitre wrote:
> > > Seconded.
> > >
> > > Having git-checkout $foo being a shorthand for git checkout -b $foo
> > > origin/$foo when origin/$foo exists and $foo doesn't is definitely handy.
> >
> > No. This is only the first step towards insanity.
> >
> > In many cases origin/$foo == origin/master so this can't work in that
> > case which is, after all, the common case.
>
> I don't understand that argument at all, can you explain further?
By default, git creates a branch called "master. Hence, by default, if
you clone that repository, this branch will be called origin/master. So
by default $foo is already ambiguous.
> > Therefore I think this is
> > wrong to add magic operations which are not useful for the common case
> > and actively _hide_ how git actually works. Not only will you have to
> > explain how git works anyway for that common origin/master case, but
> > you'll also have to explain why sometimes the magic works and sometimes
> > not. Please keep such convenience shortcuts for your own scripts and/or
> > aliases.
>
> It's not about magic, it's about sensible defaults. Currently this use
> case is an error, and the resultant command is very long to type, and
> involves typing the branch name twice. I end up writing things like:
>
> git checkout -b {,origin/}wr34251-do-something
>
> For the user who doesn't know to use the ksh-style {} blocks this is
> voodoo. The longer form is cumbersome.
This is no excuse for promoting semantics only useful in such special
cases.
> For the case where the thing you type is a resolvable reference, it
> would just check it out, as now.
As long as it checks it out with a detached head if it is a remote
branch then I have no issue.
Nicolas
--
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
