Re: DWIM "git checkout frotz" to "git checkout -b frotz origin/frotz"

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Jun 8, 2010, 08:07 UTC
Message-ID: <4C0DFA55.8070800@drmicha.warpmail.net>
In-Reply-To: <20100607193226.GA19789@localhost>

Clemens Buchacher venit, vidit, dixit 07.06.2010 21:32:

Show 22 quoted lines

> On Mon, Jun 07, 2010 at 09:17:25PM +0200, Matthieu Moy wrote:
>> Clemens Buchacher <drizzd@aon.at> writes:
>>
>>> But this is supposedly a feature which helps users who type "git
>>> checkout <branch>" by mistake, when they really wanted to do "git
>>> checkout -t <remote>/<branch>".
>>
>> Not sure what's the argument here, but aren't the two commands
>> equivalent? Do you prefer the second syntax "git checkout -t
>> <remote>/<branch>"? It's already a DWIM for "git checkout -b <branch>
>> -t <remote>/<branch>", and I find this one far more confusing:
>>
>> git checkout    <remote>/<branch> => detaches HEAD
>> git checkout -t <remote>/<branch> => creates a local branch automatically
> 
> The intent with -t is clear. It is used only when you create a new
> branch. Also, you specify the remote branch you're going to create
> a new branch from.
> 
> "git checkout <branch>", on the other hand, will create a branch
> based on a remote branch, even though you neither asked for a new
> branch, nor did you specify any remote at all.

You're making a very important point here:

The existing DWIMery executes *different commands* depending on the circumstances (<branch> existing or not). "checkout" and "checkout -t/-b" really are different commands.

For me, DWIMery is OK in these cases:

- completing refs (<name> may be refs/heads/<name> or refs/tags/<name> etc.)

- Adding options without which the other options don't make sense
(independent of the circumstances), such adding "-b" for "-t", or, even
doing the DWIMery above since "--track" is requested explicitly.

Changing the command (mode) is something fundamentally different.

[In this specific case, it also keeps the user from learning what's going on, but that's a different issue.]

But I'm afraid it's too late.

Michael