Re: Git User's Survey 2007 unfinished summary (long)

["Shawn O. Pearce" <spearce@spearce.org>]

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Thu, 4 Oct 2007, Jakub Narebski wrote:
> > 26. Which porcelains do you use?
> > 
> > Multiple answers (one can use more than one porcelain).
> > 
> >   Answer (multiple choice)       | Count
...
> >   other                          | 14
...
> > Those 14 "other" answers make me wish to have provided "if other,
> > what it was?" (sub)question; actually not only for this question.
> 
> git-gui, of course.  I consider it porcelain, because it uses core-git as 
> backend.

I tried to get git-gui into this list as a choice as I really do
consider it porcelain but Jakub thought it wasn't and wanted to
have a specific category for GUIs.  Whatever.  Its probably all
git-gui and qgit users that picked other here.  Probably in about
the same ratio too, so 8 git-gui's and 6 qgit's.

For the most part git-gui tries to only ever invoke plumbing.  I
break that rule in only three places:

  - git-merge: I'm lazy and didn't have time yet to rewrite this
               properly using Tcl.  I already do about half of the
               work anyway (e.g. merge base testing, fast-forward
               detection, message formatting).

  - git-fetch: Now that this is in C I'm going to call it plumbing
               even if nobody else does.  Especially for say HTTP
               as git-fetch process does all of the HTTP requests
               directly.  I won't reimplement it in Tcl, it would
               be slower and suck more.  So git-gui won't be calling
               git-fetch-pack anytime soon.

  - git push: Same as the above reason for git-fetch.

IMHO, porcelain is anything that only invokes plumbing.  Seats
however can sit above porcelain to make the position slightly
more comfortable.  :-)

> In the same vein, I should consider gitk porcelain now, since it has 
> rebase capabilities.  I will not, and I am not very happy that this viewer 
> got a non-view-only capability, instead of git-gui, where that feature 
> should have belonged (as suggested by at least one answer to a later 
> question in the survey -- not by me).

I agree.  I actually never use the modification features of gitk.
They are so hidden that most users don't even know they are there.
Of course that's just as hidden as the hunk selection in git-gui
is so I shouldn't be complaining.

I'm seriously looking at implementing those modification features
into git-gui and will probably start work on some of that during
the trip.  I got plenty of time in a sealed tube at 30,000 feet
to kill.  More time than I got battery packs for the laptop.  :-\

I think the first thing to implement is cherry-pick and revert as
those are easy and co-workers have been asking about them.  That way
you can then rebase using cherry-pick and the Mark I wetware loop.
Then we need a cool graph thing that you can drag the nodes around
on to create a visual `rebase -i`.

-- 
Shawn.