git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Shawn O. Pearce <spearce@spearce.org>
Date
Aug 9, 2007, 03:26 UTC
Message-ID
<20070809032610.GA24573@spearce.org>
In-Reply-To
<85lkclrdpr.fsf@lola.goethe.zz>
David Kastrup <dak@gnu.org> wrote:
Show 6 quoted lines
> 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.
Previous: David KastrupNext: David Kastrup
Message 5 of 10 in “Mod. gitk to support REBASE (with stash support).”
  1. Mod. gitk to support REBASE (with stash support).Alexandre Bourget, Aug 8, 2007
  2. Peter BaumannAug 8, 2007
  3. Johannes SchindelinAug 8, 2007
  4. David KastrupAug 8, 2007
  5. Shawn O. PearceAug 9, 2007
  6. David KastrupAug 9, 2007
  7. Shawn O. PearceAug 9, 2007
  8. Shawn O. PearceAug 9, 2007
  9. David KastrupAug 9, 2007
  10. Junio C HamanoAug 8, 2007

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.