[petsc-dev] Reminder planning release soon

[Barry Smith]

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