demerphq venit, vidit, dixit 08.06.2010 10:18: > On 8 June 2010 10:07, Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> wrote: >> Clemens Buchacher venit, vidit, dixit 07.06.2010 21:32: >>> On Mon, Jun 07, 2010 at 09:17:25PM +0200, Matthieu Moy wrote: >>>> Clemens Buchacher <drizzd@xxxxxx> 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. > > "checkout a branch" is the command. The rest is just bookkeeping. I'm sorry but that is just plain silly. We have several "commands" which do very different things depending on options, i.e. comprise different commands/command modes - which is why I used the phrase command (mode) in the part you chose to leave out. One mode is checking out an existing branch. One mode is creating a new branch and checking it out, i.e. doing a "git branch" followed by a "git checkout" proper. Current DWIMery switches from the first to the second depending on your existing branches. The only reason this could sneak in is the fact that it is non-destructive, just (over-) eagerly constructive. Michael -- 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