Re: [PATCH] Documentation: add a planning document for the next CLI revamp

On Thu, 30 Oct 2008, Sam Vilain wrote:

On Thu, 2008-10-30 at 12:53 -0400, Nicolas Pitre wrote:

quoted

quoted

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.

quoted

  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