[PYRITE] Status update and call for information.

[PYRITE] Status update and call for information.

[Govind Salinas]

Hey Folks,

I am still around working on Pyrite.  Which is both a porcelain and a
git/Python library.  I have been making some good progress recently
on my way to my alpha release and I thought I would share my progress
and get some feedback.

Status:

Although work and life keep me pretty busy, I have made good progress
on rounding out the use cases for Pyrite.  I can do most of my day's
SCM work in pyrite and it really just lacks a couple features before
I can, theoretically, use it all the time.  Hopefully I will be able
to tag alpha in a couple weeks.

Interface:

I have been doing a lot of thinking about what kind of interface
would make this easily accessable to new and casual users and I have
some ideas where I want to go.  Actually, I have taken most of the
ideas from other SCMs such as Mercurial and Bazaar in addition to git.

One of the things that has been commented on by almost any review of
git are the large numbers of commands that are present and the
endless stream of flags, options, configuration variables and
syntaxes that are present in git.  They certainly serve a purpose
and I probably would not be able to do this without all those things
but it can get in a normal users way some times.  Here are some of
the steps I have and will be taking.

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

Clone a new repo
pyt checkout http://foo.com/bar/baz.git mybaz

It's a URL, I know that I can clone that and I know I am not inside
a repository.

Fetch
pyt co <url> # or remote:origin

It's a URL, but I am inside the repo, I should tell the user that
they are about to fetch something.

Pull
pyt co -m remote:origin:branch

Pull is just fetch/merge anyway -m tells it to merge, perhaps a flag -u
to do it all in one step.

Merge
pyt co -m localbranchhead

Checkout a branch
pyt co localbranchead # or remote:origin:branch, tag:tagname etc

Create/switch to new local branch (this should look familiar)
pyt co -c <newbranch> -b <base>

The list goes on.


2) Reduce complexity.

This one is easy, not because there are commands in git that don't
have a use, but because we can usually spell stuff in a simpler way.
Take for example master@{100}.  If I see someone on the list use that
on I might expect that that is master 100 commits ago, rather than what
HEAD was pointing at 100 operations ago.  Furthermore, if I have just
cloned, that won't work because I have no reflog.  So what if we
spelled that reflog:100:master?  Well now at least I know that I
am dealing with the reflog.  Perhaps a more refined spelling could
give the user more information.

Take ":/message"  I didn't even know that existed until I was looking
for nifty things to spell, but wouldn't "subject:my subject" work just
as well?  Thats a little friendlier.

How about not using the ".." and "..." since it can be surprising to
users what they actually do without understanding how git works.
Perhaps something like --revision-start (-r) and --revision-end(-R)
would help them out.  Add a --symmetric or something for "...".

You get the idea.

3) Addons.

Some functionality isn't for everyone.  I have just put into my
next branch an addon that gives git revision numbers.  Why, because
other SCMs that are supposed to be more user friendly have them.
Because people have been asking for them.  Because they are easier
to remember.  The concept is this.  A given commit encapsulates its
parantage, so if I have commit XYZ, I can always say that XYZ is
so-many commits away from the first commit.  The question is how
you determine that number and that you always do it the same.  If
we just define the revision number to be the place of the commit
in the list of "git rev-list --topo-order --reverse SHA1" then
we can get a consistant number semi-meaningful number, which is all
people really want.

So why isn't this for everyone?  Because its a little slow and some
people on the list HATE anything that takes more than half a
second.  I won't name names but he has an OS named after him.  So for
a git repo on decent hardware, this adds .5-1 seconds to look something
up and find out its revision.  Painful to some, but others would
rather wait than have to try and remember a SHA1 or even just the
first 8 chars of a SHA1.

4) GUI.

I have a GUI in mind, I haven't had time to work on it, but I have
started it and the idea is that it should be able to completely
replace the command line.  Why?  because some people hate command lines
and more importantly, because I want a GUI that will look like it
fits into my Gnome desktop and looks decent on my Windows machine
(which I use because I have to).

5) One stop shop.

I tried setting up Apache, lighttpd etc on Windows to do some ad-hoc
serving of a git repo.  I was painful.  I want my webserver, gui,
command line, diff tool, merge tool to all come in one package.  And
I DON'T want it to need a cygwin or msys installation to work.

That just makes life easier.  And I am all about the not expending
effort.


Well, this mail is long enough, hopefully I will get some feedback
on this, some more ideas for things that can be simplified or
enhanced or whatever.  Please feel free to drop me a line and/or
check out my public repo at http://gitorious.org/projects/pyrite.

Thanks,
Govind.

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

[Karl Hasselström]

On 2008-05-23 01:18:42 -0500, Govind Salinas wrote:

> Some functionality isn't for everyone. I have just put into my next
> branch an addon that gives git revision numbers. Why, because other
> SCMs that are supposed to be more user friendly have them. Because
> people have been asking for them. Because they are easier to
> remember. The concept is this. A given commit encapsulates its
> parantage, so if I have commit XYZ, I can always say that XYZ is
> so-many commits away from the first commit. The question is how you
> determine that number and that you always do it the same. If we just
> define the revision number to be the place of the commit in the list
> of "git rev-list --topo-order --reverse SHA1" then we can get a
> consistant number semi-meaningful number, which is all people really
> want.

You do realize that no matter how you define your sequential numbers,
they can't be both globally consistent and unique? (That is, either
different repositories will assign different numbers to the same
commit, or the same number could be assigned to more than one commit.)

For a simple reason: A numbering that's both globally consistent and
unique can only look at a commit's ancestry (and the commit itself)
when assigning a number to a commit. But in order to get _sequential_
numbers, you need to look at the commit's siblings as well, and the
set of siblings can be different from repository to repository.

This has already been discussed to death elsewhere in this list at
least once (see the list archives), but your next paragraph suggests
you think it's only a performance issue, which is why I brought it up:

> So why isn't this for everyone? Because its a little slow and some
> people on the list HATE anything that takes more than half a second.
> I won't name names but he has an OS named after him. So for a git
> repo on decent hardware, this adds .5-1 seconds to look something up
> and find out its revision. Painful to some, but others would rather
> wait than have to try and remember a SHA1 or even just the first 8
> chars of a SHA1.

> Well, this mail is long enough, hopefully I will get some feedback
> on this, some more ideas for things that can be simplified or
> enhanced or whatever. Please feel free to drop me a line and/or
> check out my public repo at http://gitorious.org/projects/pyrite.

Good luck with your work!

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

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

[Govind Salinas]

On Fri, May 23, 2008 at 1:45 AM, Karl Hasselström <kha@treskal.com> wrote:
> On 2008-05-23 01:18:42 -0500, Govind Salinas wrote:
>
>> Some functionality isn't for everyone. I have just put into my next
>> branch an addon that gives git revision numbers. Why, because other
>> SCMs that are supposed to be more user friendly have them. Because
>> people have been asking for them. Because they are easier to
>> remember. The concept is this. A given commit encapsulates its
>> parantage, so if I have commit XYZ, I can always say that XYZ is
>> so-many commits away from the first commit. The question is how you
>> determine that number and that you always do it the same. If we just
>> define the revision number to be the place of the commit in the list
>> of "git rev-list --topo-order --reverse SHA1" then we can get a
>> consistant number semi-meaningful number, which is all people really
>> want.
>
> You do realize that no matter how you define your sequential numbers,
> they can't be both globally consistent and unique? (That is, either
> different repositories will assign different numbers to the same
> commit, or the same number could be assigned to more than one commit.)
>
> For a simple reason: A numbering that's both globally consistent and
> unique can only look at a commit's ancestry (and the commit itself)
> when assigning a number to a commit. But in order to get _sequential_
> numbers, you need to look at the commit's siblings as well, and the
> set of siblings can be different from repository to repository.
>
> This has already been discussed to death elsewhere in this list at
> least once (see the list archives), but your next paragraph suggests
> you think it's only a performance issue, which is why I brought it up:
>

Of course, no one makes the claim that rev numbers are unique or
even that a commit has the same revision number between branches
in the same repository.   Hg states that flat out and I believe bzr says
the same, although I am pretty sure they determine their numbers some
other way.  I make no such claim.  What I do claim is that for a given
branch, a commit should always have the same revision number.  Sure,
If you merge a commit from another branch, it's revnum might change,
but that is ok.  As long as, assuming you have not re-written master,
10:master will always point to the same commit I think I am providing
something worth while.  Also, AFAIK the order of parentage is part of
the hash that makes a commit ID, so if my master is a clone of your
master, it should share revision numbers.

Thanks,
Govind.

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

[Karl Hasselström]

On 2008-05-23 07:36:25 -0500, Govind Salinas wrote:

> On Fri, May 23, 2008 at 1:45 AM, Karl Hasselström <kha@treskal.com>
> wrote:
>
> > You do realize that no matter how you define your sequential
> > numbers, they can't be both globally consistent and unique? (That
> > is, either different repositories will assign different numbers to
> > the same commit, or the same number could be assigned to more than
> > one commit.)
>
> Of course, no one makes the claim that rev numbers are unique or
> even that a commit has the same revision number between branches in
> the same repository. Hg states that flat out and I believe bzr says
> the same, although I am pretty sure they determine their numbers
> some other way. I make no such claim. What I do claim is that for a
> given branch, a commit should always have the same revision number.
> Sure, If you merge a commit from another branch, it's revnum might
> change, but that is ok. As long as, assuming you have not re-written
> master, 10:master will always point to the same commit I think I am
> providing something worth while. Also, AFAIK the order of parentage
> is part of the hash that makes a commit ID, so if my master is a
> clone of your master, it should share revision numbers.

Yes, with those restrictions it can be made to work. (What confused me
was that you brought up performance as the only reason to prefer
hashes to your rev numbers. But hashes also have the advantage that
they're immutable, whereas your rev numbers are not.)

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

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

[Jakub Narebski]

"Govind Salinas" <blix@sophiasuchtig.com> writes:

> One of the things that has been commented on by almost any review of
> git are the large numbers of commands that are present and the
> endless stream of flags, options, configuration variables and
> syntaxes that are present in git.  They certainly serve a purpose
> and I probably would not be able to do this without all those things
> but it can get in a normal users way some times.  Here are some of
> the steps I have and will be taking.

Which is bogus, because most of those commands are plumbing, [almost]
never to be used by user directly.

If I understand correctly in next major git release those commands are
to be hidden and not present in PATH anymore.
 
> 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.

> Clone a new repo
> pyt checkout http://foo.com/bar/baz.git mybaz
> 
> It's a URL, I know that I can clone that and I know I am not inside
> a repository.
> 
> Fetch
> pyt co <url> # or remote:origin
> 
> It's a URL, but I am inside the repo, I should tell the user that
> they are about to fetch something.

Not necessary, you might have wanted to have repository inside
repository, either managed using submodules, or ignored, etc.

> Pull
> pyt co -m remote:origin:branch
> 
> Pull is just fetch/merge anyway -m tells it to merge, perhaps a flag -u
> to do it all in one step.
> 
> Merge
> pyt co -m localbranchhead
> 
> Checkout a branch
> pyt co localbranchead # or remote:origin:branch, tag:tagname etc
> 
> Create/switch to new local branch (this should look familiar)
> pyt co -c <newbranch> -b <base>
> 
> The list goes on.

Note also that if you make all those unrelated (at least a bit) things
into one command you would lose some of error detection.  For example
you want to clone, but due to typo and DWIM-mery of "pyt co" command
it would silently fetch/merge/branch/whatever.  Not good...

Note also that another complaint is that git commands do many fairly
independent things... and you would want to escalate it even
further...

> 2) Reduce complexity.
> 
> This one is easy, not because there are commands in git that don't
> have a use, but because we can usually spell stuff in a simpler way.
> Take for example master@{100}.  If I see someone on the list use that
> on I might expect that that is master 100 commits ago, rather than what
> HEAD was pointing at 100 operations ago.

Errr... master 100 commits ago (in first-parent line) is master~100.
And that it is not where HEAD was (indirectly or directly) pointing,
but where 'master' ref was pointing.

The ref@{n} notation is very, very useful when you want to correct
mistakes such as errorneous rewind ("git reset --hard HEAD^" for
example), or botched rebase, or to view pre-rebase version to compare,
etc.

>  Furthermore, if I have just
> cloned, that won't work because I have no reflog.  So what if we
> spelled that reflog:100:master?  Well now at least I know that I
> am dealing with the reflog.  Perhaps a more refined spelling could
> give the user more information.
> 
> Take ":/message"  I didn't even know that existed until I was looking
> for nifty things to spell, but wouldn't "subject:my subject" work just
> as well?  Thats a little friendlier.
> 
> How about not using the ".." and "..." since it can be surprising to
> users what they actually do without understanding how git works.
> Perhaps something like --revision-start (-r) and --revision-end(-R)
> would help them out.  Add a --symmetric or something for "...".

You don't need two options; first -r is start, second -r is end...
 
> You get the idea.

True, the fact that revisions are non-option parameters, and that
pathspecs are also non-option parameters might be a bit confusing to
newbie.

On the other hand the a..b and a...b notation is matter of convenience
(it is easier to use than "b ^a" or "a b --not $(git merge-base a
b)"); perhaps allowing a..b and a...b notation for git-diff was an
error... but it makes copy'n'paste easier...

> 3) Addons.
> 
> Some functionality isn't for everyone.  I have just put into my
> next branch an addon that gives git revision numbers.  Why, because
> other SCMs that are supposed to be more user friendly have them.
> Because people have been asking for them.  Because they are easier
> to remember.  

Because people does not understand the concept and constraints of
distributed version control system (with implied multiple branches and
nonlinear history).

Revision numbers cannot be all of: decentralized, global, unchanging,
encompassing.  

(Decentralized means no single authority assigning numbers, and no
repositories which are special in any case for example using
merge/pull with different options than other repositories.  Global
means that all repositories have the same numbers for the same
revisions; the opposite is local, that numbers are relevant only in
your local repository (and you cannot say: in revision 'n' to someone
else).  Unchanging means that revsision numbers don't change on pull
for example.  Encompassing means that all revisions are given number.)

> 4) GUI.
> 
> I have a GUI in mind, I haven't had time to work on it, but I have
> started it and the idea is that it should be able to completely
> replace the command line.  Why?  because some people hate command lines
> and more importantly, because I want a GUI that will look like it
> fits into my Gnome desktop and looks decent on my Windows machine
> (which I use because I have to).

Have you checked existing git GUIs, both history viewers and commit
tools?  Gitk, git-gui, QGit, Giggle, ugit, tig,...
 
> 5) One stop shop.
> 
> I tried setting up Apache, lighttpd etc on Windows to do some ad-hoc
> serving of a git repo.  I was painful.  I want my webserver, gui,
> command line, diff tool, merge tool to all come in one package.  And
> I DON'T want it to need a cygwin or msys installation to work.
> 
> That just makes life easier.  And I am all about the not expending
> effort.

Perhaps we could just get more examples in gitweb/README and perhaps
in user's manual.

BTW. there always is git-instaweb.

But having git-serve would be nice...

-- 
Jakub Narebski
Poland
ShadeHawk on #git

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

[Govind Salinas]

On Fri, May 23, 2008 at 8:07 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> "Govind Salinas" <blix@sophiasuchtig.com> writes:
>
>> One of the things that has been commented on by almost any review of
>> git are the large numbers of commands that are present and the
>> endless stream of flags, options, configuration variables and
>> syntaxes that are present in git.  They certainly serve a purpose
>> and I probably would not be able to do this without all those things
>> but it can get in a normal users way some times.  Here are some of
>> the steps I have and will be taking.
>
> Which is bogus, because most of those commands are plumbing, [almost]
> never to be used by user directly.
>
> If I understand correctly in next major git release those commands are
> to be hidden and not present in PATH anymore.
>

That may be true but it is only part of the story.  I see plumbing commands
being given to users all the time on the mailing list.  Usually in some
combination.  To make it worse they usually get several sets of commands
that do something similar but any one may or may not be exactly what
they want because not everyone who responds fully understands what the
commands are doing.

I think I can reduce the number of commands to around 25 total with 10 or
so that a user might use regularly.  But it is an experiment, we will see
where it goes.

>> 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.  Its about the
commands doing what I want without me having to research it.

>> Fetch
>> pyt co <url> # or remote:origin
>>
>> It's a URL, but I am inside the repo, I should tell the user that
>> they are about to fetch something.
>
> Not necessary, you might have wanted to have repository inside
> repository, either managed using submodules, or ignored, etc.
>

Good point.  But that could be done with a submodule command or
by following the create with the ignore, say..

pyt config ignore <dir>
pyt co <url> <dir>

<dir> is not in this repo, therefore we are cloning to it.  Worst case
there would be a flag for it in the command, since this is the
unusual case, it would be ok to force the user to do a little more
typing.

>> Pull
>> pyt co -m remote:origin:branch
>>
>> Pull is just fetch/merge anyway -m tells it to merge, perhaps a flag -u
>> to do it all in one step.
>>
>> Merge
>> pyt co -m localbranchhead
>>
>> Checkout a branch
>> pyt co localbranchead # or remote:origin:branch, tag:tagname etc
>>
>> Create/switch to new local branch (this should look familiar)
>> pyt co -c <newbranch> -b <base>
>>
>> The list goes on.
>
> Note also that if you make all those unrelated (at least a bit) things
> into one command you would lose some of error detection.  For example
> you want to clone, but due to typo and DWIM-mery of "pyt co" command
> it would silently fetch/merge/branch/whatever.  Not good...
>
> Note also that another complaint is that git commands do many fairly
> independent things... and you would want to escalate it even
> further...
>

I will just have to do it right then :)  Seriously, I am not afraid to
experiment
with this to get the commands right.  Perhaps some of these can't be
combined, but that is no reason not to see if it works.  Besides, DWIM is
not enough, in needs to be "DWIM Safely".

>> 2) Reduce complexity.
>>
>> This one is easy, not because there are commands in git that don't
>> have a use, but because we can usually spell stuff in a simpler way.
>> Take for example master@{100}.  If I see someone on the list use that
>> on I might expect that that is master 100 commits ago, rather than what
>> HEAD was pointing at 100 operations ago.
>
> Errr... master 100 commits ago (in first-parent line) is master~100.
> And that it is not where HEAD was (indirectly or directly) pointing,
> but where 'master' ref was pointing.
>
> The ref@{n} notation is very, very useful when you want to correct
> mistakes such as errorneous rewind ("git reset --hard HEAD^" for
> example), or botched rebase, or to view pre-rebase version to compare,
> etc.
>

I know that, and you know that, but the command and the syntax don't
tell you that.  I only know that because I spent a night[1] going over the
docs and making sure I had it right, before that I had seen the notation
on the mailing list several times but never really understood it.

>>
>> How about not using the ".." and "..." since it can be surprising to
>> users what they actually do without understanding how git works.
>> Perhaps something like --revision-start (-r) and --revision-end(-R)
>> would help them out.  Add a --symmetric or something for "...".
>
> You don't need two options; first -r is start, second -r is end...
>

Maybe, I prefer to be explicit and its a little less work for me.  Let me
ask you this.  Is there a down side to having 2 different names?  If I
say "pyt log -r foo" do I mean "..foo" or "foo.."?

>> 3) Addons.
>>
>> Some functionality isn't for everyone.  I have just put into my
>> next branch an addon that gives git revision numbers.  Why, because
>> other SCMs that are supposed to be more user friendly have them.
>> Because people have been asking for them.  Because they are easier
>> to remember.
>
> Because people does not understand the concept and constraints of
> distributed version control system (with implied multiple branches and
> nonlinear history).
>
> Revision numbers cannot be all of: decentralized, global, unchanging,
> encompassing.
>
> (Decentralized means no single authority assigning numbers, and no
> repositories which are special in any case for example using
> merge/pull with different options than other repositories.  Global
> means that all repositories have the same numbers for the same
> revisions; the opposite is local, that numbers are relevant only in
> your local repository (and you cannot say: in revision 'n' to someone
> else).  Unchanging means that revsision numbers don't change on pull
> for example.  Encompassing means that all revisions are given number.)
>

I responded to this in another mail.  The other DVCSs don't claim that
revision numbers are all of those things.  It is only necessary that when
two people say the same thing, it mean the same thing.

To quote the Hg wiki at
http://www.selenic.com/mercurial/wiki/index.cgi/RevisionNumber?highlight=(rev)

"Revision numbers referring to changesets are very likely to be
different in another copy of a repository. Do not use them to talk about
changesets with other people. Use the changeset ID instead."

This doesn't stop them from using these numbers more than the sha1
IDs because given a branch, the numbers are solid.  Doing things the
way I propose has the same properties.

>> 4) GUI.
>>
>> I have a GUI in mind, I haven't had time to work on it, but I have
>> started it and the idea is that it should be able to completely
>> replace the command line.  Why?  because some people hate command lines
>> and more importantly, because I want a GUI that will look like it
>> fits into my Gnome desktop and looks decent on my Windows machine
>> (which I use because I have to).
>
> Have you checked existing git GUIs, both history viewers and commit
> tools?  Gitk, git-gui, QGit, Giggle, ugit, tig,...
>

Yes I have looked at most of them, and all of them have something (or
even many things) I want but none of them have everything.  Giggle
has the UI I want, gitk and git-gui have most of the functionality.  ugit
has some nice features that the others don't.

>> 5) One stop shop.
>>
>> I tried setting up Apache, lighttpd etc on Windows to do some ad-hoc
>> serving of a git repo.  I was painful.  I want my webserver, gui,
>> command line, diff tool, merge tool to all come in one package.  And
>> I DON'T want it to need a cygwin or msys installation to work.
>>
>> That just makes life easier.  And I am all about the not expending
>> effort.
>
> Perhaps we could just get more examples in gitweb/README and perhaps
> in user's manual.
>

Examples won't help too much on windows, partially because its just a pain
in the ass to do, but also because thats not the preferred platform for any
of the tools.  I was using cygwin git at the time and it simply did not work.
Perhaps it has gotten better in the last few months particularly with
msysgit.

> BTW. there always is git-instaweb.
>

Yeah, but I still need the webserver, thats what I want to get rid of.  If you
want to do some ad-hoc sharing it is a huge problem and you may not
have permissions/time to install software.

> But having git-serve would be nice...
>

Indeed.

-Govind

[1] Ok, a couple of hours anyway.

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

[Jakub Narebski]

"Govind Salinas" <blix@sophiasuchtig.com> writes:

What I forgot to ask: how would you compare Pyrite to similar tool,
namely to EasyGit?

> On Fri, May 23, 2008 at 8:07 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> "Govind Salinas" <blix@sophiasuchtig.com> writes:
>>
>>> One of the things that has been commented on by almost any review of
>>> git are the large numbers of commands that are present and the
>>> endless stream of flags, options, configuration variables and
>>> syntaxes that are present in git.  They certainly serve a purpose
>>> and I probably would not be able to do this without all those things
>>> but it can get in a normal users way some times.  Here are some of
>>> the steps I have and will be taking.
>>
>> Which is bogus, because most of those commands are plumbing, [almost]
>> never to be used by user directly.
>>
>> If I understand correctly in next major git release those commands are
>> to be hidden and not present in PATH anymore.
> 
> That may be true but it is only part of the story.  I see plumbing commands
> being given to users all the time on the mailing list.  Usually in some
> combination.  To make it worse they usually get several sets of commands
> that do something similar but any one may or may not be exactly what
> they want because not everyone who responds fully understands what the
> commands are doing.

The change to "git help" to show only porcelain commands unless
explicitely requested, and to git(7) manpage to have porcelain first
would help there.

But I think using plumbing in examples are remainder of git early
days, where it was the only way to work with git.  Tools like Pyrite,
or EasyGit, wouldn't change it...

>>> 1) Reduce the number of commands.
[...]
>> Note also that if you make all those unrelated (at least a bit) things
>> into one command you would lose some of error detection.  For example
>> you want to clone, but due to typo and DWIM-mery of "pyt co" command
>> it would silently fetch/merge/branch/whatever.  Not good...
>>
>> Note also that another complaint is that git commands do many fairly
>> independent things... and you would want to escalate it even
>> further...
>>
> 
> I will just have to do it right then :)  Seriously, I am not afraid to
> experiment
> with this to get the commands right.  Perhaps some of these can't be
> combined, but that is no reason not to see if it works.  Besides, DWIM is
> not enough, in needs to be "DWIM Safely".

I think you should start not with "minimal number of commands" as a
goal, but rather with set of distinct tasks ordinary (not scripting)
user might need, and how to map them into commands.
 
To heavily overloaded commands are as much if not worse than having
too many commands to choose from.

> >> 2) Reduce complexity.
[...]
>>> How about not using the ".." and "..." since it can be surprising to
>>> users what they actually do without understanding how git works.
>>> Perhaps something like --revision-start (-r) and --revision-end(-R)
>>> would help them out.  Add a --symmetric or something for "...".
>>
>> You don't need two options; first -r is start, second -r is end...
>>
> 
> Maybe, I prefer to be explicit and its a little less work for me.  Let me
> ask you this.  Is there a down side to having 2 different names?  If I
> say "pyt log -r foo" do I mean "..foo" or "foo.."?

Ah, yes, good catch.
 
>>> 3) Addons.
>>>
>>> Some functionality isn't for everyone.  I have just put into my
>>> next branch an addon that gives git revision numbers.  Why, because
>>> other SCMs that are supposed to be more user friendly have them.
>>> Because people have been asking for them.  Because they are easier
>>> to remember.
>>
>> Because people does not understand the concept and constraints of
>> distributed version control system (with implied multiple branches and
>> nonlinear history).
>>
>> Revision numbers cannot be all of: decentralized, global, unchanging,
>> encompassing.
[...] 
> I responded to this in another mail.  The other DVCSs don't claim that
> revision numbers are all of those things.  It is only necessary that when
> two people say the same thing, it mean the same thing.

> This doesn't stop them from using these numbers more than the sha1
> IDs because given a branch, the numbers are solid.  Doing things the
> way I propose has the same properties.

I wonder how useful in practice those revision numbers are in larger
repositories, with nonlinear history, i.e. if -r 6453:master -R 6455:master
(or something like that) is truly easier to use than master~2..master 

I _think_ that sha-1 are largely theoretical scare, as for example I
don't use them much, and if I use them it is in copy'n'paste manner.

>>> 5) One stop shop.
>>>
>>> I tried setting up Apache, lighttpd etc on Windows to do some ad-hoc
>>> serving of a git repo.  I was painful.  I want my webserver, gui,
>>> command line, diff tool, merge tool to all come in one package.  And
>>> I DON'T want it to need a cygwin or msys installation to work.
>>>
>>> That just makes life easier.  And I am all about the not expending
>>> effort.
>>
>> Perhaps we could just get more examples in gitweb/README and perhaps
>> in user's manual.
>>
> 
> Examples won't help too much on windows, partially because its just a pain
> in the ass to do, but also because thats not the preferred platform for any
> of the tools.  I was using cygwin git at the time and it simply did not work.
> Perhaps it has gotten better in the last few months particularly with
> msysgit.
> 
>> BTW. there always is git-instaweb.
>>
> 
> Yeah, but I still need the webserver, thats what I want to get rid of.  If you
> want to do some ad-hoc sharing it is a huge problem and you may not
> have permissions/time to install software.
> 
>> But having git-serve would be nice...
>>
> 
> Indeed.

And with Python AFAIK you can quite easily set up _simple_ web server
for HTTP access and browsing repository...

BTW. there was at some time git web interface in Python (old wit), but
it lost to gitweb; nowadays Ruby, eRuby or Ruby on Rails seems to be
the rage (new Wit (from XMMS2), Gitarella, Gitorious, GitHub).

-- 
Jakub Narebski
Poland
ShadeHawk on #git

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

[Govind Salinas]

On Sat, May 24, 2008 at 3:41 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> "Govind Salinas" <blix@sophiasuchtig.com> writes:
>
> What I forgot to ask: how would you compare Pyrite to similar tool,
> namely to EasyGit?
>

I think the main difference is this, from the first bullet on the eg site
http://www.gnome.org/~newren/eg/

"eg focuses on documentation and examples"

EasyGit is more or less a thin wrapper over git that is fully compatible
(AFAIK).  Elijah can correct me where I am wrong, but I see it as git
training wheels for the command line.  That probably sounds
pejorative but I don't mean it that way.  I am taking the opportunity
to break compatibility in order to see if I can improve usability.  Also, I
don't want to just focus on the command line, I want to affect all areas.

>> On Fri, May 23, 2008 at 8:07 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>>> "Govind Salinas" <blix@sophiasuchtig.com> writes:
>>>
>>>> One of the things that has been commented on by almost any review of
>>>> git are the large numbers of commands that are present and the
>>>> endless stream of flags, options, configuration variables and
>>>> syntaxes that are present in git.  They certainly serve a purpose
>>>> and I probably would not be able to do this without all those things
>>>> but it can get in a normal users way some times.  Here are some of
>>>> the steps I have and will be taking.
>>>
>>> Which is bogus, because most of those commands are plumbing, [almost]
>>> never to be used by user directly.
>>>
>>> If I understand correctly in next major git release those commands are
>>> to be hidden and not present in PATH anymore.
>>
>> That may be true but it is only part of the story.  I see plumbing commands
>> being given to users all the time on the mailing list.  Usually in some
>> combination.  To make it worse they usually get several sets of commands
>> that do something similar but any one may or may not be exactly what
>> they want because not everyone who responds fully understands what the
>> commands are doing.
>
> The change to "git help" to show only porcelain commands unless
> explicitely requested, and to git(7) manpage to have porcelain first
> would help there.
>
> But I think using plumbing in examples are remainder of git early
> days, where it was the only way to work with git.  Tools like Pyrite,
> or EasyGit, wouldn't change it...
>

The idea is that there should be one fairly obvious way to do something.
If you have that then there is less confusion, especially when someone
asks for help.  Plus, if there is one fairly obvious way to do something,
then people will need to ask for help less often.  That is what I hope to
accomplish.

>>>> 1) Reduce the number of commands.
> [...]
> I think you should start not with "minimal number of commands" as a
> goal, but rather with set of distinct tasks ordinary (not scripting)
> user might need, and how to map them into commands.
>
> To heavily overloaded commands are as much if not worse than having
> too many commands to choose from.
>

This is true.  This idea is fairly new and I am still deciding exactly
how things
would get broken up.  After thinking about it, "checkout" probably should
not be combined with the fetch/pull/merge command because they are
too different.  Here is how I am thinking of combining things, perhaps you
and others can give some pointers on what is crazy and what might work.

The ones prefixed with * are the ones that would show up in the short
help, the ones that would be the most typically used.

  bisect = bisect
  blame = blame
* commit = commit + push + stash + init
          push:  This is here because it fits the traditional notion of what a
                    commit does, which is to send a commit to the central
                    server.  I think of it as "I am committing my changes to
                    the remote repository.
          stash:  What is stash but a temporary commit (not on the branch)?
          init: This can be done a couple of ways, either your initial
                  commit is combined with the init or --init is a flag
                  passed to commit to set up the NULL commit.  At least
                  thats how I think of it conceptually.
* checkout = checkout + clone + branch + remote
* config = config
  cherry = cherry + cherry-pick
* diff = diff
  gc = clean + gc + prune + repack
         I plan to make full use of gc --auto to avoid having the
         user run this command, but everyone knows there
         are reasons to run these commands even with --auto.
         "Clean" seems to me to be the working directory version
         of gc.
* gui = gui
* help = help
  import = apply + cvsimport + <scm>import + am
         Here the import strategies would be provided by addons
         and such with apply/am as standard.
  mail = format-patch + send-mail
  move = move
* pull = pull, fetch, merge
  rebase = rebase
  remove = remove
* resolve = mergetool
  revert = reset + reflog
          I was thinking of calling this command "recover" instead of
          revert, which I still think might describe what I want to do
          and might tell you why I think that reflog is something to
          combine here.  "revert --what-can-i-revert-to" would show
          the output of reflog.  That wouldn't be the actual name
          of the flag, but it gives you the idea.
* serve
* show = show + ls + log + grep + rev-list + rev-parse + describe
          Combining all this may raise a few eye-brows, but I think
          it makes sense.  Really this command is git log + ls-files +
          describe and the ability of showing files from other revisions
          from git show, the rest can be reduced to functionality already
          available in git log.
* status = status
  submodule
  tag
* track = add/addremove
  verify = fsck

>> >> 2) Reduce complexity.
> [...]
>>>> 3) Addons.
[snip problems with revision numbers]
> [...]
>> I responded to this in another mail.  The other DVCSs don't claim that
>> revision numbers are all of those things.  It is only necessary that when
>> two people say the same thing, it mean the same thing.
>
>> This doesn't stop them from using these numbers more than the sha1
>> IDs because given a branch, the numbers are solid.  Doing things the
>> way I propose has the same properties.
>
> I wonder how useful in practice those revision numbers are in larger
> repositories, with nonlinear history, i.e. if -r 6453:master -R 6455:master
> (or something like that) is truly easier to use than master~2..master
>
> I _think_ that sha-1 are largely theoretical scare, as for example I
> don't use them much, and if I use them it is in copy'n'paste manner.
>

They are useful for a different purpose.  If I say master~5 today it
probably won't yield the same commit tomorrow.  while 6450:master would.
Honestly, I have absolutely no problem with using sha1s myself, I just put
this in because I have seen several people ask for it on the mailing list
recently.  I thought to myself, that they COULD have it if they really wanted.
Also keep in mind that 12345: is usually enough as an empty RHS would
default to HEAD, which saves a bit of typing.

>>>> 5) One stop shop.
[snip windows + webserver headaches]
>>> BTW. there always is git-instaweb.
>>>
>>
>> Yeah, but I still need the webserver, thats what I want to get rid of.  If you
>> want to do some ad-hoc sharing it is a huge problem and you may not
>> have permissions/time to install software.
>>
>>> But having git-serve would be nice...
>>>
>>
>> Indeed.
>
> And with Python AFAIK you can quite easily set up _simple_ web server
> for HTTP access and browsing repository...
>
> BTW. there was at some time git web interface in Python (old wit), but
> it lost to gitweb; nowadays Ruby, eRuby or Ruby on Rails seems to be
> the rage (new Wit (from XMMS2), Gitarella, Gitorious, GitHub).
>
I was thinking of using Django so that I could reuse the stuff that the
review-board folks are doing.  I like their side-by-side diffs etc.  But here
is the kicker, I want to use this to do what the hg people have done.
They built their remote push-pull functionality into their built-in webserver.
If we do this then the pyrite http protocol can be a smart transport.  I
believe that bzr has a similar feature in theirs.

Thanks for taking a look and giving me your opinion, I like getting
feedback about this.

-Govind

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

[Dmitry Potapov]

On Fri, May 23, 2008 at 06:07:34PM -0700, Jakub Narebski wrote:
> 
> On the other hand the a..b and a...b notation is matter of convenience
> (it is easier to use than "b ^a" or "a b --not $(git merge-base a
> b)"); perhaps allowing a..b and a...b notation for git-diff was an
> error... but it makes copy'n'paste easier...

I believe that the error was how these operations were defined for diff.
I would rather expect to 'git diff a..b' to produce the accumulative
patch of 'git log -p a..b', but currently 'git diff a..b' is equivalent
of 'git diff a b', and this is redundant and confusing. As to 'git diff
a...b', it would be nice if it showed three way diff. At least, it is
how I would define them if I were writing some front-end.

Dmitry

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

[Dmitry Potapov]

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.

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

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

[Jakub Narebski]

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.

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

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

[Govind Salinas]

On Sat, May 24, 2008 at 3:47 PM, Jakub Narebski <jnareb@gmail.com> 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@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.

> 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

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

[Jakub Narebski]

On Sat, 24 May 2008, Dmitry Potapov wrote:
> On Fri, May 23, 2008 at 06:07:34PM -0700, Jakub Narebski wrote:
>> 
>> On the other hand the a..b and a...b notation is matter of convenience
>> (it is easier to use than "b ^a" or "a b --not $(git merge-base a
>> b)"); perhaps allowing a..b and a...b notation for git-diff was an
>> error... but it makes copy'n'paste easier...
> 
> I believe that the error was how these operations were defined for diff.
> I would rather expect to 'git diff a..b' to produce the accumulative
> patch of 'git log -p a..b', but currently 'git diff a..b' is equivalent
> of 'git diff a b', and this is redundant and confusing. 

I think "git diff a..b" and "git diff a...b" (which is cute hack) were
created to allow copy'n'paste from git-fetch result messages, not only
to git-log but also for git-diff; note that in case of git-fetch
messages a..b is always fast-forward (a = merge-base a b).

I think that both solutions for "git diff a..b", be it "git diff a b"
or "git diff $(git merge-base a b) b" can be argued for, soe historical
reasons (a...b was added later) and backward compatibility wins.

> As to 'git diff a...b', it would be nice if it showed three way diff.
> At least, it is how I would define them if I were writing some
> front-end. 

At least "git diff --cc a...b" and "git diff -c a...b", i.e. diff as
if there were a merge... although now that I look at it it seems to
be more difficult than on first glance.

-- 
Jakub Narebski
Poland

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

[Jakub Narebski]

On Sat, 24 May 2008, Govind Salinas wrote:
> On Sat, May 24, 2008 at 3:41 AM, Jakub Narebski wrote:
>> "Govind Salinas" <blix@sophiasuchtig.com> writes:

>>>>> 1) Reduce the number of commands.
>> [...]
>> I think you should start not with "minimal number of commands" as a
>> goal, but rather with set of distinct tasks ordinary (not scripting)
>> user might need, and how to map them into commands.
>>
>> To heavily overloaded commands are as much if not worse than having
>> too many commands to choose from.
> 
> This is true.  This idea is fairly new and I am still deciding exactly
> how things would get broken up.  After thinking about it, "checkout"
> probably should not be combined with the fetch/pull/merge command
> because they are too different.  Here is how I am thinking of
> combining things, perhaps you and others can give some pointers on
> what is crazy and what might work. 
> 
> The ones prefixed with * are the ones that would show up in the short
> help, the ones that would be the most typically used.
> 
>   bisect = bisect
>   blame = blame
> * commit = commit + push + stash + init
>           push:  This is here because it fits the traditional notion
>           of what a commit does, which is to send a commit to the
>           central server.  I think of it as "I am committing my
>           changes to the remote repository.

That I'm not sure about. One of advantages of _distributed_ SCM is
separation of the act of committing (saving state to repository) and 
publishing (making those changes public, which stops changing history).
So I'd rather left commit and push separate, although I can agree that
local / public commit would be not so bad alternate interface.

>           stash:  What is stash but a temporary commit (not on the
>           branch)?

I think that is (might be) a good idea, _BUT_ with the caveat that after 
stash working repository is in state _before_ changes.  But that might 
work.

>           init: This can be done a couple of ways, either your initial
>                   commit is combined with the init or --init is a flag
>                   passed to commit to set up the NULL commit.  At
>                   least thats how I think of it conceptually.

Bad, bad idea.  First, init is _very_ separate thing from commit.  
Second, you would lose I think much of error detection.  And last, 
sometimes yoy initialize repository (usually bare repository) to 
propagate changes not using commit (local commit), but using push 
(remote commit).

> * checkout = checkout + clone + branch + remote

No.  'clone' = 'init' + 'remote', or 'clone' ~= 'import'.
Overloading 'checkout' to do all the work of 'branch' is
IMHO not a good idea.

Here it looks like you want to cram too much into single command.
You have fewer commands, but only superficially; you have actually have 
them, but disguised as options and special cases and DWIM-mery.

> * config = config
>   cherry = cherry + cherry-pick

Errr... cherry has nothing to do with cherry-pick.  I'd think
that cherry could be an option to git-log instead, and cherry-pick
be joined with revert.

> * diff = diff

>   gc = clean + gc + prune + repack
>          I plan to make full use of gc --auto to avoid having the
>          user run this command, but everyone knows there
>          are reasons to run these commands even with --auto.

git-gc already is meant to be porcelain for prune and repack,
so you should need run only this command.

>          "Clean" seems to me to be the working directory version
>          of gc.

git-clean is potentially dangerous.  It is _not_ garbage collecting.
Besides "git-clean" apes "make clean"... actually this (the possibility 
of mistake) migh be a good argument for making git-clean to be special 
case of git-gc.

> * gui = gui
> * help = help

>   import = apply + cvsimport + <scm>import + am
>          Here the import strategies would be provided by addons
>          and such with apply/am as standard.

It is one on wishlist from some time to be able to fetch / clone from 
other SCMs just by providing URL to foreign SCM, i.e. unified foreign 
SCM import and foreign SCM interaction support.

>   mail = format-patch + send-mail

I'm not that sure.  Perhaps.  Or perhaps format-patch should be special 
case of git-log (or option to git-log).

>   move = move

> * pull = pull, fetch, merge

Merge is separate from pull because it is inherently local.  Pull might 
get data from remote repository.  And I guess it would play merry hell 
with remotes (shortcuts for remote repositories URLs and refspecs), and 
remote branches names.

>   rebase = rebase
>   remove = remove

> * resolve = mergetool

>   revert = reset + reflog
>           I was thinking of calling this command "recover" instead of
>           revert, which I still think might describe what I want to do
>           and might tell you why I think that reflog is something to
>           combine here.  "revert --what-can-i-revert-to" would show
>           the output of reflog.  That wouldn't be the actual name
>           of the flag, but it gives you the idea.

Mercurial if I remember correctly uses "backout" for git-revert 
equivalent.  Perhaps "rewind" would be better name for git-reset.

> * serve

> * show = show + ls + log + grep + rev-list + rev-parse + describe
>           Combining all this may raise a few eye-brows, but I think
>           it makes sense.  Really this command is git log + ls-files +
>           describe and the ability of showing files from other
>           revisions from git show, the rest can be reduced to
>           functionality already available in git log.

I think that having git-log to show series of commits, and git-show for 
individual, _single_ objects (be it tree, working area, blob, commit, 
tag, current revision name = git-describe) would be better idea.

git-rev-list and git-rev-parse are deep plumbing, not usually to be used 
by end user.

> * status = status 
>   submodule
>   tag

> * track = add/addremove

Ehhh? I'd leave add/rm/mv/cp as is.  Having those commands do not add
(much) to complexity.

>   verify = fsck
[...]

>>>>> 5) One stop shop.
> [snip windows + webserver headaches]
>>>> BTW. there always is git-instaweb.
>>>
>>> Yeah, but I still need the webserver, thats what I want to get rid
>>> of.  If you want to do some ad-hoc sharing it is a huge problem and
>>> you may not have permissions/time to install software.
>>>
>>>> But having git-serve would be nice...
>>>>
>>>
>>> Indeed.
>>
>> And with Python AFAIK you can quite easily set up _simple_ web server
>> for HTTP access and browsing repository...
>>
>> BTW. there was at some time git web interface in Python (old wit),
>> but it lost to gitweb; nowadays Ruby, eRuby or Ruby on Rails seems to
>> be the rage (new Wit (from XMMS2), Gitarella, Gitorious, GitHub).
>>
> I was thinking of using Django so that I could reuse the stuff that
> the review-board folks are doing.  I like their side-by-side diffs
> etc.  

It would be nice to have yet another web interface...

> But here is the kicker, I want to use this to do what the hg 
> people have done.  They built their remote push-pull functionality
> into their built-in webserver.  If we do this then the pyrite http
> protocol can be a smart transport.  I believe that bzr has a similar
> feature in theirs. 

I think that git dumb HTTP/HTTPS transport would conflict with pyt-serve 
smart http transport / tunnelling of git protocol over http.

Besides, HTTP as protocol has its disadvantages, for example it is 
sessionless if I remember correctly...

-- 
Jakub Narebski
Poland

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

[Jan Krueger]

Hi,

allow me to play the devil's advocate here.

Your approach is to combine different concepts that are similar and can
be used to do the same thing but in completely different ways. Wouldn't
this actually create more confusion than keeping these concepts
separate? Examples follow.

> The idea is that there should be one fairly obvious way to do
> something. If you have that then there is less confusion, especially
> when someone asks for help.  Plus, if there is one fairly obvious way
> to do something, then people will need to ask for help less often.

If people didn't ask things like "how do I delete a file", I'd be more
inclined to believe that. ;)

Now, on to the fun part.

> * commit = commit + push + stash + init
>           push:  This is here because it fits the traditional notion
> of what a commit does, which is to send a commit to the central
>                     server.  I think of it as "I am committing my
> changes to the remote repository.

The problem I see there is that it will be difficult to include the
part of push that sends several commits at once. It is a very common
workflow to create a series of local commits, test them, possibly
rewrite them in several ways, and finally push the entire set. To have
your combined command do that, you'd need something like "pyt commit
--to-remote --use-new-local-commits". Is that better than "pyt
push" (and does describing this as "committing" actually make sense)? I
think not. It's sacrificing convenience and sense for reducing the
visible number of commands.

>           stash:  What is stash but a temporary commit (not on the
> branch)?

This is correct, but only technically. In fact, a commit is something
that you'll typically share with others, whereas a stash is not. This
makes me doubt it's helpful to combine both.

> * checkout = checkout + clone + branch + remote

Checkout already has a doubtful duality: it can either switch branches
or check out a specific version of a single file. I don't think
capitalizing on the 'switch branches' concept while keeping the other
function is a good idea. At the very least, consider splitting "fetch
other version of this file" into a separate command.

I can see another source of confusion here: with this, checkout can
either create a new repo or a new branch in the same repo. In other
words, what it does depends on the context you call it in. This is a
no-no in interface design.

Finally, "remote" could just as well go with pull or push (which is
what it's actually used for in practice). The act of defining or
removing a remote is misplaced here since it has nothing to do with
checking anything out.

>   gc = clean + gc + prune + repack

See Jakub's comment about that. I strongly agree with him.

> * pull = pull, fetch, merge

Unlike what Jakub says, I can imagine this working well in the
distributed case. It could be a command that does both fetch and merge
by default and you can switch off either. It would make little sense
when merging a number of local branches, however.

>   revert = reset + reflog

Keep in mind that you need to stick git-revert somewhere, too.

> (still revert)
>           I was thinking of calling this command "recover" instead of
>           revert, which I still think might describe what I want to do
>           and might tell you why I think that reflog is something to
>           combine here.  "revert --what-can-i-revert-to" would show
>           the output of reflog.

Another source of confusion, since I almost never use the reflog for
git-reset. I almost always use a commit ID or something like HEAD^, or
no argument at all (mostly for reset --hard).

> * track = add/addremove

That would only make sense if you hide the index completely. I think
that's a bad idea, because the index is a really powerful thing. At the
very least, add -i gets impossible if there's no way of influencing the
index directly.

It would be a lot better to keep commit -a (and perhaps hint at it if
commit is called with an unchanged index) and define something like the
following:

* stage (or record, take, use) -- same as git-add.
* remove (rm) -- same as git-rm. Probably good to rename --cached.
* unstage (or unrecord) -- revert index to version in last commit.

> They are useful for a different purpose.  If I say master~5 today it
> probably won't yield the same commit tomorrow.  while 6450:master
> would.

That's right, but keep in mind that revision numbers will probably make
people think revision numbers are global, e.g. "hey Bill, check out
revision 3488 I committed today" (and Bill gets it as 3754). The
background of either CVS or SVN would encourage this.

Also, 6450:master, as a syntax, doesn't cut it. What if in the past of
master, a merge commit with seven parents happened? It's impossible to
figure out which parent to follow. You'd have to write something like
45;1:357,4:774 (go back 45 commits, take parent 1, go back 357 commits,
etc.). Just numbering all commits in master's past according to
depth-first search, on the other hand, will just make revision numbers
very confusing.

Something else to consider is that revision numbers are hardly better
to remember than (abbreviated) commit IDs. Consider KDE's SVN repository
with (currently) 812270 revisions...

> I just put this in because I have seen several people ask for it on
> the mailing list recently.  I thought to myself, that they COULD have
> it if they really wanted.

But with a number of important disadvantages. Sometimes it really is
better not to have everything you want.

In conclusion, your goal is a good one, but it's something that
requires a lot of very careful consideration. To name just one thing,
you need to make it consistent, clean, and still powerful enough to not
stand in the way of moderately (un)common tasks.

I believe there is a bit of a tendency in your approach to emulate
commands of other VCS, and that's not the right way to go if you ask me.
If I did something like pyt (and I won't lie, I have put some thought
into it, including writing down a couple of ideas), I would start with a
clean slate and design something that really makes sense (which neither
the current git nor any other existing interface stacked on top of it
can really deliver). David Roundy did this well for darcs, I think: a
great number of commands have different names than in the classic VCS,
but they all make a lot of sense. Still, again, darcs's commands
wouldn't work that well for git; both systems are just too different.

Something else that's worth considering is that an interface to git is
not just about reshuffling commands; it's also about behaviour. For
example, submodules as they currently are are a bit hard to use
correctly (from what I've read on IRC; I haven't used them myself yet),
and refspecs are rather non-intuitive to use (especially push :foo).

It'll be interesting to see how the various existing alternative
interfaces to git will address all these problems.

-- 
Best regards
Jan Krueger
Aachen, Germany

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

[Jakub Narebski]

Dnia sobota 24. maja 2008 23:50, Govind Salinas napisał:
> On Sat, May 24, 2008 at 3:47 PM, Jakub Narebski <jnareb@gmail.com> 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@gmail.com> wrote:
>>>>> "Govind Salinas" <blix@sophiasuchtig.com> writes:
>>>>>
>>>>>> 1) Reduce the number of commands.
[...]
>>>>
>>>> Sure, removing commands is not about removing features, its about
>>>> reducing the learning curve and reducing confusion.

IMHO pushing too much into single commands do not reduce confusion
but increases it.

[Searching for a good example...] For example 'mv' could be modified
to include functionality of 'rm' in the form of 'mv file-to-delete',
but nobody sane would think of doing it.  Another example: you can
use 'less' to view contents of directory, but you usually use 'ls'
to do that; and nobody sane would think of extending 'less' to accept
all 'ls' switches, to have all 'ls' functionality.



I also think that having 30+ commands does not steep learning curve
make.  For example GNU coreutils only consist of 90 commands, but base
CLI is not that hard to use.

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

Do not cater to least common denominator, please. 

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

I think git notion of branch is clean, and clearly superior to the crap
othe SCMs use ;-P.  I'd like to remind you that multiple branches in
single repository were something added at user request, at least
according to Junio's FLOSS weekly #19 follow-up in his blog
  http://gitster.livejournal.com/9970.html

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

Note that "git checkout" defaults to HEAD.

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

These three are all about listing metadata, refs to be more exact.
'checkout' is IMHO all about getting given state recorded in repository
(or, in git case, also from index) into working area, i.e. in a way
opposite to 'commit' or 'checkin', at least as far as it is possible.
So I think this is in the same league as using 'less' to view contents
(listing) of a directory.  This IMHO does not reduce confusion, but
adds to it.

Also note that git-branch is used to create and list branches
(unfortunately it uses -l for --enable-reflog and not for --list as
other commands like git-tag do), but can be also used to delete and
rename branches.  Do you want to stuff this functionality in "pyt co"?

> pyt co <branch>
>   checkout the branch, looking at refs

It is the default.

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

Please note that result of this is very, very different from ordinary
checkout.  Either it doesn't touch working area if it is equivalent
of git-fetch, or can result in conflicts and not a clean state if
it is equivalent of git-pull.

> pyt co -n mynewbranch [start=HEAD]
>   creates and checks out a new branch.

Simply different name for option, I think.

> pyt co [something=HEAD] [--] <files>...
>   should be obvious

But it isn't obvious.  

Let me explain.  Because in git commits are always whole-tree
snapshots, and usually (read: almost always) it makes sense to have
whole-tree commits in an SCM, this cannot switch branches.  So for
example there is a question if it is a separate mode (yet another
oveloading of 'pyt co' operator) of checkout changing working area
without changing current branch (something like svn-revert,
or hg-undo), or would it make HEAD detached and result in something
like not yet implemented "git cherry-pick <rev> -- <files>".

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

This is not 'checkout', mind you.

> pyt co -d [-f] <branch-name> | <uri> | <remote>
>   delete a branch or stop tracking a remote.

Oh, so you do plan to stuff at least deleting branches and remotes
in 'pyt co'?

What was the UNIX motto: do one thing, and do it well?


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

And it looks like you gone to far in the reducing number of commands
direction and do not see disadvantages of heavily overloaded, DWIM-ming,
doing multiple different things depending on options commands.  If you
don't like large number of commands (is 30+ large number?), use GUI!


What you need is to have some _users_ to tell you if you do with
Pyrite in good direction.  Or at least analysis of common git workflows
and how they could be improved...

-- 
Jakub Narebski
Poland

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

[Govind Salinas]

On Sun, May 25, 2008 at 4:23 AM, Jan Krueger <jk@jk.gs> wrote:
> Hi,
>

Hey.
> allow me to play the devil's advocate here.
>
> Your approach is to combine different concepts that are similar and can
> be used to do the same thing but in completely different ways. Wouldn't
> this actually create more confusion than keeping these concepts
> separate? Examples follow.

I think it is highly dependent on how you organize it.

>> The idea is that there should be one fairly obvious way to do
>> something. If you have that then there is less confusion, especially
>> when someone asks for help.  Plus, if there is one fairly obvious way
>> to do something, then people will need to ask for help less often.
>
> If people didn't ask things like "how do I delete a file", I'd be more
> inclined to believe that. ;)
>
> Now, on to the fun part.
>
>> * commit = commit + push + stash + init
>>           push:  This is here because it fits the traditional notion
>> of what a commit does, which is to send a commit to the central
>>                     server.  I think of it as "I am committing my
>> changes to the remote repository.
>
> The problem I see there is that it will be difficult to include the
> part of push that sends several commits at once. It is a very common
> workflow to create a series of local commits, test them, possibly
> rewrite them in several ways, and finally push the entire set. To have
> your combined command do that, you'd need something like "pyt commit
> --to-remote --use-new-local-commits". Is that better than "pyt
> push" (and does describing this as "committing" actually make sense)? I
> think not. It's sacrificing convenience and sense for reducing the
> visible number of commands.

I have responded to most of this in other mails, but I think it bears
repeating.  In most cases, when combining commands, it should be
possible to do so without adding a ton of flags.  Otherwise, you are correct,
it would not help anything.  In some cases it does make sense to add a flag
to mimic another command.

Take cherry/cherry-pick for example.  These commands are related even
though they don't do the same thing.  Because they are useful in combination
it makes some sense (to me) that I would ask the cherry command both for
"what is pickable" and to actually do the picking.  Does that make sense?
Of course you would do this with a flag.

But onto the current example.  Try and the command working like this...

pyt ci [what to checkin] [where to checkin to]

[what to commit] defaults to the changes in your working directory.  It can
also be a subset of these.  In this case [where to checkin to] would most
likely be the local branch.  Whether it is allowed to checkin directly to a
remote repository is not something I am convinced about one way or the
other.

Now if you look at at that it is possible to write.

pyt ci branch:foo remote:origin:foo

No flags are needed, and it could probably be simplified to

pyt ci foo remote:origin:foo

or even

pyt ci foo origin:foo

depending on how much mind reading we want to do.  Personally
I see that as just as simple as the git equivalent without the need of
an added command.

>>           stash:  What is stash but a temporary commit (not on the
>> branch)?
>
> This is correct, but only technically. In fact, a commit is something
> that you'll typically share with others, whereas a stash is not. This
> makes me doubt it's helpful to combine both.

Again let us think of this as

pyt ci [what to checkin] [where to checkin to]

if I then say

pyt ci stash:[name]

I am saying [what to checkin] is the default (changes in the working set)
and [where to checkin to] is the stash.  This, again makes sense to me
and you would later

pyt co stash:<name>

to get it back.

It seems to be nicely symmetric.

>> * checkout = checkout + clone + branch + remote
>
> Checkout already has a doubtful duality: it can either switch branches
> or check out a specific version of a single file. I don't think
> capitalizing on the 'switch branches' concept while keeping the other
> function is a good idea. At the very least, consider splitting "fetch
> other version of this file" into a separate command.

You could be right about that, the checkout files functionality might
fit better in the "recover" command.  It makes language sense as
well, if you catch my meaning.  Meaning that when I checkout a file
I could say to myself "i want to recover the version of the file from
X commit."

> I can see another source of confusion here: with this, checkout can
> either create a new repo or a new branch in the same repo. In other
> words, what it does depends on the context you call it in. This is a
> no-no in interface design.

Actually, I was suggesting that "checkin" would incorporate the init
command, not "checkout."  The idea being that you can just skip
the init step.  I don't see this as being much different from
"git clone" which could be seen as short for

git init && git pull <uri>

except now it would be

git init && git commit ...

> Finally, "remote" could just as well go with pull or push (which is
> what it's actually used for in practice). The act of defining or
> removing a remote is misplaced here since it has nothing to do with
> checking anything out.

Please look at the following example and tell me if it makes more
sense.

Again, we define checkout as...

pyt co [what do i want to checkout] [where do i want to checkout to]

so if I say

pyt co git://foo.com/bar.git mybar

this would translate to

git remote add -f mybar git://foo.com/bar.git
git fetch mybar

I have checked git://foo.com/bar.git to refs/remotes/mybar and as a
convenience I have set up tracking for you.

Any pull/fetch/merge done after this could take advantage of the
remote having been set up.

>>   gc = clean + gc + prune + repack
>
> See Jakub's comment about that. I strongly agree with him.

Er, ok.  I am actually not sure that Jakub and I disagree on this point.
He says prune and repack are already absorbed by gc and he says
that clean could be seen as a special case of gc.  Perhaps I
misunderstood him?

>> * pull = pull, fetch, merge
>
> Unlike what Jakub says, I can imagine this working well in the
> distributed case. It could be a command that does both fetch and merge
> by default and you can switch off either. It would make little sense
> when merging a number of local branches, however.
>
>>   revert = reset + reflog
>
> Keep in mind that you need to stick git-revert somewhere, too.
>
>> (still revert)
>>           I was thinking of calling this command "recover" instead of
>>           revert, which I still think might describe what I want to do
>>           and might tell you why I think that reflog is something to
>>           combine here.  "revert --what-can-i-revert-to" would show
>>           the output of reflog.
>
> Another source of confusion, since I almost never use the reflog for
> git-reset. I almost always use a commit ID or something like HEAD^, or
> no argument at all (mostly for reset --hard).

I have decided on --show-reflog to try and reduce any potential confusion.
Does that sound better?  Please look at the help from the following
file and let me know if you think that is still confusing.

http://gitorious.org/projects/pyrite/repos/blixs-clone/blobs/wip/pyrite/standard/recover.py

All that aside, how does this sound?  A revert/recover command that
does the following, it can do a "git reset --hard" to revert your current
changes.  If you want to revert just one or more files then it would
evaluate out to be "git checkout HEAD -- <files>..."  But it could
recover to a previous state by giving it a commit id.  Then have a
separate reverse-commit command that does what git-revert does.
Part of the reason I think this is useful is that "revert" means different
things to different people, but using "recover" and "reverse-commit"
make more sense.  Also, it avoids the confusion you were talking about
earlier with checkout being too overloaded with the file stuff and the
branch stuff.

>> * track = add/addremove
>
> That would only make sense if you hide the index completely. I think
> that's a bad idea, because the index is a really powerful thing. At the
> very least, add -i gets impossible if there's no way of influencing the
> index directly.

I like having my cake and eating it too.  I intend to hide the index AND
let the user take advantage of it.  I intend to do this by postponing
its use until commit time, at which point the user would have the
option of being --picky about what they want to commit.  At that point
I would do something like "git add -i" or "git add -p" to let them
choose.  This lets them do partial commits while never having to
think about whether they have staged the right information (in the
normal case).

> It would be a lot better to keep commit -a (and perhaps hint at it if
> commit is called with an unchanged index) and define something like the
> following:
>
> * stage (or record, take, use) -- same as git-add.
> * remove (rm) -- same as git-rm. Probably good to rename --cached.
> * unstage (or unrecord) -- revert index to version in last commit.

I don't quite follow, perhaps an example would make things clearer?

[regarding revision number]
>> They are useful for a different purpose.  If I say master~5 today it
>> probably won't yield the same commit tomorrow.  while 6450:master
>> would.
>
> That's right, but keep in mind that revision numbers will probably make
> people think revision numbers are global, e.g. "hey Bill, check out
> revision 3488 I committed today" (and Bill gets it as 3754). The
> background of either CVS or SVN would encourage this.

Please read my other mails, I address this a couple times.  Other
DVCSs make great use of revision numbers without the property you
talk about.  They understand that these numbers aren't necessarily
portable like that.  However, once a commit is in a branch, it will
always have the same position in *that* branch.

> Also, 6450:master, as a syntax, doesn't cut it. What if in the past of
> master, a merge commit with seven parents happened? It's impossible to
> figure out which parent to follow. You'd have to write something like
> 45;1:357,4:774 (go back 45 commits, take parent 1, go back 357 commits,
> etc.). Just numbering all commits in master's past according to
> depth-first search, on the other hand, will just make revision numbers
> very confusing.

This is just the current git syntax back to front.  If you read my mail you
see that I define it according to --topo-order which makes a consistent
ordering of the parents.

> Something else to consider is that revision numbers are hardly better
> to remember than (abbreviated) commit IDs. Consider KDE's SVN repository
> with (currently) 812270 revisions...

Heh, like I said, *I* don't need them, *I* like sha1s just fine.  For whatever
reason, other people are scared of the sha1s, so lets give them some
training wheels until they are more comfortable.

>> I just put this in because I have seen several people ask for it on
>> the mailing list recently.  I thought to myself, that they COULD have
>> it if they really wanted.
>
> But with a number of important disadvantages. Sometimes it really is
> better not to have everything you want.
>
> In conclusion, your goal is a good one, but it's something that
> requires a lot of very careful consideration. To name just one thing,
> you need to make it consistent, clean, and still powerful enough to not
> stand in the way of moderately (un)common tasks.

I agree completely.  This thread has been good on many levels, I has
given me a lot to think about and I have refined my ideas quite a bit
and got some very helpful suggestions.  All the things you state
here are goals of mine.

> I believe there is a bit of a tendency in your approach to emulate
> commands of other VCS, and that's not the right way to go if you ask me.
> If I did something like pyt (and I won't lie, I have put some thought
> into it, including writing down a couple of ideas), I would start with a
> clean slate and design something that really makes sense (which neither
> the current git nor any other existing interface stacked on top of it
> can really deliver). David Roundy did this well for darcs, I think: a
> great number of commands have different names than in the classic VCS,
> but they all make a lot of sense. Still, again, darcs's commands
> wouldn't work that well for git; both systems are just too different.

To be honest, my creativity is limited.  I am good at taking an existing
idea and making a new (possibly improved) application/implementation
of it.  If you have *new* ideas about this I will be happy to hear them.

> Something else that's worth considering is that an interface to git is
> not just about reshuffling commands; it's also about behaviour. For
> example, submodules as they currently are are a bit hard to use
> correctly (from what I've read on IRC; I haven't used them myself yet),
> and refspecs are rather non-intuitive to use (especially push :foo).
>
> It'll be interesting to see how the various existing alternative
> interfaces to git will address all these problems.

I really haven't thought about submodules yet.  If you have some
interface ideas I would love to hear them.  One think I would like
from submodules is for them to remember where they were on a
specific branch/commit.  So if I check out X, the submodules are
checked out to wherever they were when X was checked in.  I
don't use submodules (although I plan to) but I hear that is a
problem.

Thanks for the input.

-Govind

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

[Govind Salinas]

Trimming attributions, as they are getting hairy.

2008/5/25 Jakub Narebski <jnareb@gmail.com>:
> "Govind Salinas" <blix@sophiasuchtig.com> writes:
>>
>> 1) Reduce the number of commands.
[snip]
>> 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.
>
> Note that "git checkout" defaults to HEAD.

I do not see that as an issue.  I do not intend to have command
computability in that fashion.  However, if there is a good reason
for the default to be HEAD, then I would like to know.

>> 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.
>
> These three are all about listing metadata, refs to be more exact.
> 'checkout' is IMHO all about getting given state recorded in repository
> (or, in git case, also from index) into working area, i.e. in a way
> opposite to 'commit' or 'checkin', at least as far as it is possible.
> So I think this is in the same league as using 'less' to view contents
> (listing) of a directory.  This IMHO does not reduce confusion, but
> adds to it.

I have a theme in my commands, it is one that is in git too to some
extent.  The theme is that a command should provide both the
action and the information needed to carry out that action, making
it self contained.  Your argument could be used to argue that
"git branch" needs to be split up into "git list-branch" and
"git branch."  Now if you are saying that I should make it
"pyt co -l" to list what can be checked out, then I would think about
that, but I kind-of like the "git branch" way of doing it over the
"git-tag" way.  More a matter of taste in my opinion.

> Also note that git-branch is used to create and list branches
> (unfortunately it uses -l for --enable-reflog and not for --list as
> other commands like git-tag do), but can be also used to delete and
> rename branches.  Do you want to stuff this functionality in "pyt co"?

Yes and no, in that order.  Delete should be handled, rename is rare
enough that I would ask people to spell it

pyt co -n newname oldname
pyt co -d oldname

>> 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.
>
> Please note that result of this is very, very different from ordinary
> checkout.  Either it doesn't touch working area if it is equivalent
> of git-fetch, or can result in conflicts and not a clean state if
> it is equivalent of git-pull.

My meme for checkout/checkin is..

pyt checkout/in [what to checkout/in] [where to checkout/in to]

This would be a "set up remote & fetch", which means to me
"check out the <uri> to this remote tracking branch".  It is hopefully
a bit clearer since I have decided on making pull/fetch/merge into
a separate command following some of the earlier comments
in this thread.

>> pyt co [something=HEAD] [--] <files>...
>>   should be obvious
>
> But it isn't obvious.
>
> Let me explain.  Because in git commits are always whole-tree
> snapshots, and usually (read: almost always) it makes sense to have
> whole-tree commits in an SCM, this cannot switch branches.  So for
> example there is a question if it is a separate mode (yet another
> oveloading of 'pyt co' operator) of checkout changing working area
> without changing current branch (something like svn-revert,
> or hg-undo), or would it make HEAD detached and result in something
> like not yet implemented "git cherry-pick <rev> -- <files>".

it is "git checkout [somthing=HEAD] -- <files>..." thats why I thought it
would be obvious.  Having said that, the other option is to put this in the
recover/revert command which I have outlined in another mail.  Basically
the recover command would be "git reset --hard [somecommit=HEAD]"
with the ability to specify files rather.  Specifying files would mean to
"git checkout" the *just* files instead of the reset.  Does that sound
better?

>>>> 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.
> [...]
>> 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.
>
> And it looks like you gone to far in the reducing number of commands
> direction and do not see disadvantages of heavily overloaded, DWIM-ming,
> doing multiple different things depending on options commands.  If you
> don't like large number of commands (is 30+ large number?), use GUI!

It isn't set in stone, when I started this thread, I was thinking about 24 total
commands.  Based on feedback it is 26.  Also, using a gui only reduces
typing, the gui needs to carry forward the concepts of the underlying
system or things *really* won't make sense.

> What you need is to have some _users_ to tell you if you do with
> Pyrite in good direction.  Or at least analysis of common git workflows
> and how they could be improved...

I agree 100%.  I currently am basing this on the comments that I have
heard/read from people just starting to use git and other systems as
well as reviews I have seen posted.  I would very much like it if people
would send me comments on their experiences, both negative and
positive, while starting to use git and other DSCMs and why they
decided to stick with their result.

People seem to *like* the bzr and hg interfaces, they seem to
tolerate the git one because git has better features.  That is the
impression I get from doing my reading.

-Govind