David Kastrup <dak@xxxxxxx> wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
