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

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

[Alexandre Bourget]

---
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(-)

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

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

[Peter Baumann]

On Wed, Aug 08, 2007 at 02:33:48PM -0400, 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.
> 
> TODO: better error handling.
> 
[...long patch ...]
> +    # 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!

> +    }
> +
> +    notbusy rebasehead
> +    updatecommits
> +}

-Peter

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

[Johannes Schindelin]

Hi,

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.

Ciao,
Dscho

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

[Junio C Hamano]

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

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

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

[David Kastrup]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> 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

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

[Shawn O. Pearce]

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.

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

[David Kastrup]

"Shawn O. Pearce" <spearce@spearce.org> writes:

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

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

> 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

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

[Shawn O. Pearce]

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

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

[Shawn O. Pearce]

"Shawn O. Pearce" <spearce@spearce.org> wrote:
> 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.

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

[David Kastrup]

"Shawn O. Pearce" <spearce@spearce.org> writes:

> 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