threads / patch / 9440

patchMod. gitk to support REBASE (with stash support).

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

## tl;dr

10 messages between Aug 8, 2007 and Aug 9, 2007. Diffs are folded; open one to read it.

replies: 9people: 6as markdown or json

Alexandre Bourget· Aug 8, 2007, 18:33 UTC · lore

--- Adds a context menu for commits, so that a 'rebase' can be done.

Optionally, it will ask if you want to 'stash' current work before doing so.
TODO: better error handling.
 gitk |   38 ++++++++++++++++++++++++++++++++++++++
 1 files changed, 38 insertions(+), 0 deletions(-)
Show changes to gitk +38 −0
diff --git a/gitk b/gitk
index f74ce51..558b7bb 100755
--- a/gitk
+++ b/gitk
@@ -898,6 +898,8 @@ proc makewindow {} {
 	-command cherrypick
     $rowctxmenu add command -label "Reset HEAD branch to here" \
 	-command resethead
+    $rowctxmenu add command -label "Rebase HEAD branch on this commit" \
+	-command rebasehead
 
     set fakerowmenu .fakerowmenu
     menu $fakerowmenu -tearoff 0
@@ -5593,6 +5595,7 @@ proc rowmenu {x y id} {
     if {$id ne $nullid && $id ne $nullid2} {
 	set menu $rowctxmenu
 	$menu entryconfigure 7 -label "Reset $mainhead branch to here"
+	$menu entryconfigure 8 -label "Rebase $mainhead branch on this commit"
     } else {
 	set menu $fakerowmenu
     }
@@ -5972,6 +5975,41 @@ proc cherrypick {} {
     notbusy cherrypick
 }
 
+proc rebasehead {} {
+    global mainheadid mainhead rowmenuid confirm_ok
+    global localfrow localirow
+
+
+    set head $mainhead
+    set id $rowmenuid
+
+    set confirm_ok 0
+
+    if {$localfrow != -1 || $localirow != -1} {
+	# There's something to stash.
+	set confirm_ok [confirm_popup "There are some local modifications.\n\nDo you want to git-stash any changes before doing a rebase?\n\n(They will be reapplied right after, and stash will be *cleared*)"]
+    }
+
+    nowbusy rebasehead
+    update
+
+    if {$confirm_ok} {
+	exec git stash save
+    }
+
+    # TODO: error handling.
+    exec git rebase $id
+
+    if {$confirm_ok} {
+	exec git stash apply stash@{0}
+	exec git stash clear
+    }
+
+    notbusy rebasehead
+    updatecommits
+}
+
+
 proc resethead {} {
     global mainheadid mainhead rowmenuid confirm_ok resettype
     global showlocalchanges
-- 
1.5.3.rc4.24.g5b56a
Peter Baumann· Aug 8, 2007, 19:31 UTC · re: Alexandre Bourget · lore

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

On Wed, Aug 08, 2007 at 02:33:48PM -0400, Alexandre Bourget wrote:
Show 7 quoted lines
> ---
> Adds a context menu for commits, so that a 'rebase' can be done.
> 
> Optionally, it will ask if you want to 'stash' current work before doing so.
> 
> TODO: better error handling.
> 
[...long patch ...]
Show 5 quoted lines
> +    # TODO: error handling.
> +    exec git rebase $id
> +
> +    if {$confirm_ok} {
> +	exec git stash apply stash@{0}
'git stash apply' could fail with merge conflicts ...
> +	exec git stash clear
and here you are throwing the stash away!
Show 5 quoted lines
> +    }
> +
> +    notbusy rebasehead
> +    updatecommits
> +}
-Peter
Johannes Schindelin· Aug 8, 2007, 19:42 UTC · re: Alexandre Bourget · lore

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

Hi,
On Wed, 8 Aug 2007, Alexandre Bourget wrote:
Show 5 quoted lines
> ---
> Adds a context menu for commits, so that a 'rebase' can be done.
> 
> Optionally, it will ask if you want to 'stash' current work before doing so.
> 

You want something like this as a commit message, _not_ between "---" and diffstat.

General question: should this not be in git-gui rather than gitk? Gitk as of now is really more a viewing tool.

Ciao, Dscho

David Kastrup· Aug 8, 2007, 20:08 UTC · re: Johannes Schindelin · lore

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

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 13 quoted lines
> On Wed, 8 Aug 2007, Alexandre Bourget wrote:
>
>> ---
>> Adds a context menu for commits, so that a 'rebase' can be done.
>> 
>> Optionally, it will ask if you want to 'stash' current work before doing so.
>> 
>
> You want something like this as a commit message, _not_ between "---" and 
> diffstat.
>
> 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. It would be really nice if git-gui did not outsource its branch handling and viewing to gitk.

Could git-gui perhaps be merged with giggle at some point of time? 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.

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...

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Shawn O. Pearce· Aug 9, 2007, 03:26 UTC · re: David Kastrup · lore

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

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.
David Kastrup· Aug 9, 2007, 05:51 UTC · re: Shawn O. Pearce · lore

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

"Shawn O. Pearce" <spearce@spearce.org> writes:
Show 10 quoted lines
> 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`.

"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.

> 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.

I never claimed that it is not possible to put a rebase in there (the patch does this, after all). I just said that it does not _fit_ in there since you can't actually look at what you are rebasing on.

Show 5 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.

Show 9 quoted lines
> 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?

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.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Shawn O. Pearce· Aug 9, 2007, 06:58 UTC · re: David Kastrup · lore

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

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.
Shawn O. Pearce· Aug 9, 2007, 07:21 UTC · re: Shawn O. Pearce · lore

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

"Shawn O. Pearce" <spearce@spearce.org> wrote:
Show 6 quoted lines
> David Kastrup <dak@gnu.org> wrote:
> > other than on the current HEAD.  No diff, no file view, no rebase,
> > nothing.
> 
> So your assertion that git-gui only works with one commit, HEAD,
> is wrong.

Oh, and git-gui has some features that don't even really exist in the shell porcelain. E.g. you can do this all from the Branch->Create dialog in git-gui:

  b=refs/heads/branch-to-create
  git fetch origin foof:refs/remotes/origin/foof &&
  if test git show-ref $b
  then
    git push . refs/remotes/origin/foof:$b
  else
    git branch $b refs/remotes/origin/foof
  fi &&
  git checkout foof

That's actually somewhat hard to do on the command line, but as it turns out is just insanely handy to have for some workflows. It amounts to "Always fetch the remote tracking branch, make sure my local branch will fast-forward to it, do so, then checkout my local branch; but if the local branch doesn't exist create it, then do the checkout anyway".

I used git-push above just because its handy to do the fast-forward check and update if successful; that's not what git-gui uses internally because its actually a really stupid abuse of the push command. But it was shorter to write out the shell code for this email. Wow, OK, I just spent more time explaining why I used git-push than to just write the damn fast-forward test. Whatever.

I count 1-2 commits in that operation, depending on if your local branch exists or not. Oh, and this nifty thing called a remote.

But you are correct to some extent, there's no diff of a prior commit available from within git-gui. Or rebase. I'd like to fix both. But its time for sleep instead. Oh, and I'm supposed to be fixing some "features" of fast-import this week too...

-- 
Shawn.
David Kastrup· Aug 9, 2007, 07:55 UTC · re: Shawn O. Pearce · lore

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

"Shawn O. Pearce" <spearce@spearce.org> writes:
Show 18 quoted lines
> David Kastrup <dak@gnu.org> wrote:
>> "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.

Duh. But why are the menus called "Browse master's Files" and "Browse Branch Files" rather than "Browse heads/master" or "Browse master's head" versus "Browse any commit" or maybe just "Browse current" and "Browse at ..."? "Browse Branch Files" is _really_ misleading.

> 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.

I though about the blame window after my first posting (actually, I did not yet notice one can move around in the revisions in the blame. Nice. Now if it supported utf-8 files...). Well, yes.

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

Ok, ok. Still, commits and history are much more visible as whole in gitk: git-gui mostly lets one pick out single views (the blame window is probably the closest one gets to moving about, but then it _is_ a moving view which always shows a single point of time ultimately).

> So your assertion that git-gui only works with one commit, HEAD,
> is wrong.
Yes.
-- 
David Kastrup
Junio C Hamano· Aug 8, 2007, 19:53 UTC · re: Alexandre Bourget · lore

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

Alexandre Bourget <alexandre.bourget@savoirfairelinux.com> writes:

Show 6 quoted lines
> ---
> Adds a context menu for commits, so that a 'rebase' can be done.
>
> Optionally, it will ask if you want to 'stash' current work before doing so.
>
> TODO: better error handling.

Please do not discard a commit log message by placing them after the three-dashes. A good commit message would be of this form:

 - A single line to summarize what it does (goes to Subject);
 - A blank line (paragraph break);
 - A paragraph or more that elaborate on the above summary, if
   needed, and defend why the change is a good idea; especially
   if you considered other alternatives, a comparison to justify
   your choice.

This is largely up to Paulus, but I think anything that updates the repository should go to git-gui, not gitk. The latter is primarily a viewer.

← back to recent threads