On Sat, May 24, 2008 at 12:16:17AM -0500, Govind Salinas wrote: > On Fri, May 23, 2008 at 8:07 PM, Jakub Narebski <jnareb@xxxxxxxxx> wrote: > > "Govind Salinas" <blix@xxxxxxxxxxxxxxxxx> writes: > > > >> 1) Reduce the number of commands. > >> > >> I am currently at 30 total commands, and while I have some more to go, I > >> think there are some ways that I can get rid of some of them by > >> combining them. Do we really need a clone, branch and checkout? Don't > >> these all mean the same thing in the end? They mean get me a working > >> directory of the repository starting at X. For clone, you start > >> with 'master'. For checkout, you tell it what to get you. Branch > >> will help you manage things you can locally get. So perhaps we can > >> do something like the following... > > > > Note that you sometimes want to make a branch without checking it out. > > Also note that git-branch is overloaded to get a list of branches > > available. > > > > Sure, removing commands is not about removing features, its about > reducing the learning curve and reducing confusion. I don't see how hiding creating branch functionality behind some other command will help with learning curve or reduce confusion. If I started to use any new SCM and had to create a new branch, I would look for the "branch" command. If there is something wrong with the git-branch then it is that this command does not checkout the newly created branch by default. So, I usually create branches using git-checkout, which is counterintuitive. I don't think any commonly used SCM unites 'clone', 'branch', and 'checkout' functionality under the same name. This approach seems to be more confusing than helpful. Dmitry -- 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
