On Sat, 24 May 2008, Dmitry Potapov wrote:
> 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.
That of course depends on the point of view [1]. Branches in git
are "growth point" pointers to DAG of revisions. git-branch lists
and creates branches, and can be used to rename and delete branches
as well, and to enable reflog for branch. It does not touch working
area; separation of domains. (Note that sometimes you want to create
branch without checking it out).
git-checkout on the other hand is used to bring working area to given
state, usually from given branch (switching branches) or arbitrary
revision (detaching HEAD), but in some cases (with filename/pathspec)
from index.
Now, the seqence of
$ git branch <newbranch>
$ git checkout <newbranch>
could be written as
$ git checkout -b <newbranch>
but could have been done as
$ git branch -c <newbranch>
instead. I think it is largely matter of priorities, taste... and
of course historical reasons and backwards compatibility.
> 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.
This is also my opinion. Perhaps 'clone' and 'init', or 'clone' and
'import' could be the same command... hat might make sense...
Footnotes:
==========
[1] "The only intuitive interface is the nipple; everything else is
learned." (attribution, anyone?)
--
Jakub Narebski
Poland
--
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
