On Mar 20, 2013, at 3:59 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> > On Wed, Mar 20, 2013 at 3:57 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: > I am not objecting to having an option to create a new branch. I am object > to the use of "b" as the letter to indicate the option. > > You would prefer 'git checkout --branch new-branch-name > [optional-commit-to-start-branch-from]'? Because that works. Or you want only > 'git checkout --create-new-branch new-branch-name > [optional-commit-to-start-branch-from]'? The problem is that "branch" is the git command to create a new branch, as well as the "root" name of a bunch of operations related to branches. You have git branch name (create new branch) git branch -a (list branches) git branch -d name (delete branch) other stuff you have internalized this strange user interface so you think "git checkout --branch name" makes perfect sense. A new user who has not internalized this strange user interface sees "git checkout --branch name" (or the short -b) and thinks "ok I'm checking out the branch named name", they sure would not conclude that a new branch is being made. Once you have this moronic starting point that "branch" is both the command to create a new branch and the "root" of operations related to branches any chance of a usable user interface is already gone. You need to revisit the higher level scheme and have for example git branch --help git branch --create git branch --list etc and have git branch behave just like git --help. Do this for all the "overloaded" git commands (note that, for example, git checkout is not an "overloaded" git command, the various options only change the specific behavior of checkout, they don't make it do completely different stuff like the options to branch). Once you have these consistently named "building blocks" you need to decide IF you want a way to compose them, and if you do, on a consistent way to do the composition. So, for example, the moronic git checkout --branch newname could become (under one possible composition model) git checkout --branch --create newname and of course git checkout --branch newname would be the same as git checkout --branch --help newname which result in the help message for branch being printed in the middle of the checkout operation, useful since you didn't know what you were doing. Now I don't like this composition syntax because "composed operations" are marked with the same "--" as options to operations so maybe a "++" could be used git checkout ++branch --create newname or the short form git c +b -c newname for people who do not like to type. Consistent and clean and it is immediately clear what is composition of base commands. Next you actually have to refine the model and try it out with all the functionality you want to provide in an iterative process (thinking not only about YOUR use of the tool but all kinds of peoples use of the tool), CHANGING things until you get something good. Now I am not claiming my design above is good (I suspect it has flaws that will come up in use), only time and use and evolution would only tell but I am submitting that I have already thought more about the user interface for git at the appropriate abstract level then the git people have in the last x years since it was started. Barry
