Re: [PATCH] Mod. gitk to support REBASE (with stash support).

From: Shawn O. Pearce <spearce@spearce.org>
Date: Aug 9, 2007, 06:58 UTC
Message-ID: <20070809065810.GC24573@spearce.org>
In-Reply-To: <85odhhntmb.fsf@lola.goethe.zz>

David Kastrup <dak@gnu.org> wrote:

Show 14 quoted lines

> "Shawn O. Pearce" <spearce@spearce.org> writes:
> >> Well, yes.  But git-gui only works on a single branch head at a time,
> >> and that is not enough for rebasing.
> >
> > Sure.  But so does git's command line tools.  They tend to only
> > work on a single branch at time, the one called `HEAD`.
> 
> "tend", and many accept an explicit override: rebase accepts three
> commit names, for example.  Those that _write_ into the repository
> usually _end_ up at HEAD, but most need not start there.
> 
> And git-gui does not have any operation either looking at or working
> other than on the current HEAD.  No diff, no file view, no rebase,
> nothing.

Uh, "Repository->Browse Browse Branch Files..." will let you look at files from any commit-ish, not just HEAD or an existing branch. You can open many file browsers at once against the same commit or different commits. Double clicking a file opens it in the blame viewer, which itself can move around history a little bit.

"Merge->Local Merge..." will let you select any another commit to merge with this current branch. That's two commits.

So your assertion that git-gui only works with one commit, HEAD, is wrong.

And git-rebase taking three arguments? Its actually two; if it is given the optional final argument of the branch to rebase it first switches to that branch, then does the rebase. In other words these are identical:

  # this...
  git checkout to-rebase &&
  git rebase --onto upstreamA upstreamB

  # is the same as this...
  git rebase --onto upstreamA upstreamB to-rebase

Show 10 quoted lines

> >> Could git-gui perhaps be merged with giggle at some point of time?
> >
> > Unlikely.  A while ago I considered "Stay in Tcl/Tk or move to
> > something more 'powerful/better/faster/Linus friendly'" and stayed
> > in Tcl/Tk.  I doubt git-gui will leave Tcl/Tk.  giggle is Gtk based.
> 
> My bad: git-gui has a nice polished look on my systems (Ubuntu Feisty)
> while gitk has an ugly retro-blockish old-font Tk look; so not looking
> at the innards, I had assumed they were implemented using different
> systems.

Nope. Myself and a few others have just spent some time making git-gui look somewhat sane by default. It doesn't always; there are at least a few places where it still has too much of a Tk-ish look to it. This is especially true in a few of the dialog boxes that git-gui might open when you are about to do something potentially bad.

> User interfaces are really not what I am good at, and I don't even
> have enough time to deal with the things I am good at.

Hah.  Me neither.  Yet git-gui exists.

-- 
Shawn.