All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Shawn O. Pearce" <spearce@spearce.org>
To: David Kastrup <dak@gnu.org>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Alexandre Bourget <alexandre.bourget@savoirfairelinux.com>,
	Git Mailing List <git@vger.kernel.org>,
	paulus@samba.org
Subject: Re: [PATCH] Mod. gitk to support REBASE (with stash support).
Date: Wed, 8 Aug 2007 23:26:10 -0400	[thread overview]
Message-ID: <20070809032610.GA24573@spearce.org> (raw)
In-Reply-To: <85lkclrdpr.fsf@lola.goethe.zz>

David Kastrup <dak@gnu.org> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > General question: should this not be in git-gui rather than gitk?  Gitk as 
> > of now is really more a viewing tool.
> 
> 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`.  HEAD is
usually a symref/symlink, in which case such work is actually done
on a different branch, but doesn't have to be.  Oh, and in case
you did not know this, such single head operation *does* support
rebasing.  Bought to you by no less than *three* different flavors
of git-rebase.

So "single branch head at a time" is *not* why git-gui doesn't
support rebase.  Its because nobody has gotten around to writing it.

> It would be really nice if
> git-gui did not outsource its branch handling and viewing to gitk.

I agree, for the very reason that you mention about being able to
drag and drop commit nodes to setup a rebase.  This gets a little
hairy when you want to also drag and drop to create merges, or to
recreate merges, but its still implementable.

I have been considering loading a 'safe' interpreter and throwing
gitk into there, rather than reimplementing its rendering engine
in git-gui.  But I haven't had the time to look into how that would
work, and if there is any benefit to it.
 
> 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.

> Another option might be to let it talk with uDraw(Graph) over a
> socket: uDraw(Graph) keeps track of the graph layout and tells its
> client what has been dragged where.

Interesting.  I had not heard of this tool before.
 
> Rebasing would also be a fine operation for drag and drop on a
> graphical revision history/branch system: pull one head onto another,
> or mark one segment and pull it onto another head.  And use the reflog
> to recover from catastrophes...

Yes, I agree.  I decided that any sort of rebase operation in git-gui
must be *at least* as easy to use/user friendly as `rebase -i` is.
Anything less is just mocking the end-user.  Or something like that.
Anyway, since git-gui is restricted to a graphical interface and
most such interfaces have these pointy rodents available we can do
fancy things like dragging to express what we want to have happen,
instead of moving lines of text around.

Want to write a patch (or series of patches) for git-gui?  ;-)

-- 
Shawn.

  reply	other threads:[~2007-08-09  3:26 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-08 18:33 [PATCH] Mod. gitk to support REBASE (with stash support) Alexandre Bourget
2007-08-08 19:31 ` Peter Baumann
2007-08-08 19:42 ` Johannes Schindelin
2007-08-08 20:08   ` David Kastrup
2007-08-09  3:26     ` Shawn O. Pearce [this message]
2007-08-09  5:51       ` David Kastrup
2007-08-09  6:58         ` Shawn O. Pearce
2007-08-09  7:21           ` Shawn O. Pearce
2007-08-09  7:55           ` David Kastrup
2007-08-08 19:53 ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070809032610.GA24573@spearce.org \
    --to=spearce@spearce.org \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=alexandre.bourget@savoirfairelinux.com \
    --cc=dak@gnu.org \
    --cc=git@vger.kernel.org \
    --cc=paulus@samba.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.