On Sat, May 24, 2008 at 3:47 PM, Jakub Narebski <jnareb@xxxxxxxxx> wrote:
> 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.
>
If you will allow me to respond to both items in this mail...
In bzr both clone and branch are in the 'branch' command because every
branch is its own clone. Hg defaults to a similar way of doing things and
You clone into a new directory to get a new branch.
>From the bzr user reference:
Branch:
...
Aliases:
get, clone
...
In truth, the git notion of a branch is pretty unique among SMCs. In old
systems a branch was just a copy of a set of files at a certain point. In
other DSCMs it is more likely to be a new copy of the repo.
To answer your question a little better, I am looking at it like this:
The predominant action is, as you say, going to be "I want to create a
branch so that I can start working on something." While I respect that
you might want to create a branch and not start doing something
*right away*, I think this is less likely. So...
pyt co
this lists stuff you can checkout by which we mean local branches.
pyt co -r
this lists remote stuff you can check out, such as remote tracking
branches and the remotes themselves.
pyt co -a
lists both of the above, maybe tags too.
pyt co <branch>
checkout the branch, looking at refs
pyr co <uri> <remote-name> <branch>
the user wants to checkout something that isn't local. So we do
a git remote add -t <branch> -f <remote-name> <uri> followed by
checkout <remote-name>/<branch>
There would probably be variations/flags to get different functionality.
pyt co -n mynewbranch [start=HEAD]
creates and checks out a new branch.
pyt co [something=HEAD] [--] <files>...
should be obvious
The following are a little less intuitive, because they don't actually
result in new stuff being put in the working directory. These things are
not really a checkout activity, I will stipulate that. However, I don't think
we need one interface to do stuff with branches and remotes, one to
manage branches and one to mange remotes. And I think that users
will be able to grasp this pretty quickly.
pyt co --create-only mynewbranch
just creates without switching, it is a long option because this is not
a normal function and the user needs to understand what they are
doing.
pyt co -d [-f] <branch-name> | <uri> | <remote>
delete a branch or stop tracking a remote.
> 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>
Exactly! My first draft of the pyt branch command had a -c option
just like that.
> 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...
>
See above, they in fact do. It struck me as odd too, because I had
started with git. After thinking about it for a while, I saw advantages
to it.
-Govind
--
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
