Re: [PYRITE] Status update and call for information.

From: Govind Salinas <blix@sophiasuchtig.com>
Date: May 24, 2008, 21:50 UTC
Message-ID: <5d46db230805241450w71b0c587o4767becc0058ee0a@mail.gmail.com>
In-Reply-To: <200805242247.07565.jnareb@gmail.com>

On Sat, May 24, 2008 at 3:47 PM, Jakub Narebski <jnareb@gmail.com> wrote:

Show 32 quoted lines

> 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@gmail.com> wrote:
>>>> "Govind Salinas" <blix@sophiasuchtig.com> 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.

Show 19 quoted lines

> 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.

Show 10 quoted lines

> 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