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

[Jakub Narebski <jnareb@gmail.com>]

"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