[RFC/PATCH] gitk: Visualize a merge commit with a right-click in gitk

[RFC/PATCH] gitk: Visualize a merge commit with a right-click in gitk

[Jason Holden]

When first doing a merge in git-gui, the "Visualize Merge" button is
quite helpful to visualize the changes due to a merge.
But once the merge is complete, there's not a similarly convenient
way to recreate that merge view in gitk.

This commit adds to gitk the ability to right-click on a merge commit and
bring up a new gitk window displaying only those commits involved in
the merge.

When right-clicking on a non-merge commit, this option is grayed out.  This
patch also supports correct visualization of octopus merges

Signed-off-by: Jason Holden <jason.k.holden.swdev@gmail.com>
---
 gitk | 33 +++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/gitk b/gitk
index 379582a..17e1fcb 100755
--- a/gitk
+++ b/gitk
@@ -2551,6 +2551,7 @@ proc makewindow {} {
 	{mc "Compare with marked commit" command compare_commits}
 	{mc "Diff this -> marked commit" command {diffvsmark 0}}
 	{mc "Diff marked commit -> this" command {diffvsmark 1}}
+	{mc "Visualize this merge" command visualize_merge}
     }
     $rowctxmenu configure -tearoff 0
 
@@ -2590,6 +2591,31 @@ proc makewindow {} {
     $diff_menu configure -tearoff 0
 }
 
+# Return the number of parents for a given sha1 id
+proc get_numparents_from_id {id} {
+    global parentlist
+    set row [rowofcommit $id]
+    return [llength [lindex $parentlist $row]]
+}
+
+proc visualize_merge {} {
+    global parents currentid parentlist
+    global rowmenuid
+
+    set num_parents [get_numparents_from_id $rowmenuid]
+    set row [rowofcommit $rowmenuid]
+
+    if {$num_parents >= 2} {
+	set revlist $rowmenuid
+	for { set i 1 } {$i < $num_parents} {incr i} {
+
+	    set revlist "$revlist [lindex $parentlist $row 0]..[lindex $parentlist $row $i] $rowmenuid"
+	}
+	
+	eval exec gitk $revlist
+    }
+}
+
 # Windows sends all mouse wheel events to the current focused window, not
 # the one where the mouse hovers, so bind those events here and redirect
 # to the correct window
@@ -8577,6 +8603,13 @@ proc rowmenu {x y id} {
 	$menu entryconfigure 9 -state $mstate
 	$menu entryconfigure 10 -state $mstate
 	$menu entryconfigure 11 -state $mstate
+
+	# Disable visualize-merge on only one parent
+	if {[get_numparents_from_id $id] == 1} {
+	    $menu entryconfigure 15 -state disabled
+	} else {
+	    $menu entryconfigure 15 -state normal
+	}
     } else {
 	set menu $fakerowmenu
     }
-- 
1.8.1.rc3.28.g0ab5d1f

Re: [RFC/PATCH] gitk: Visualize a merge commit with a right-click in gitk

[Paul Mackerras]

On Sat, Dec 29, 2012 at 07:16:16PM -0500, Jason Holden wrote:

> When first doing a merge in git-gui, the "Visualize Merge" button is
> quite helpful to visualize the changes due to a merge.
> But once the merge is complete, there's not a similarly convenient
> way to recreate that merge view in gitk.
> 
> This commit adds to gitk the ability to right-click on a merge commit and
> bring up a new gitk window displaying only those commits involved in
> the merge.
> 
> When right-clicking on a non-merge commit, this option is grayed out.  This
> patch also supports correct visualization of octopus merges

Thanks for the patch.  I have a couple of comments about it.  First,
the exec command waits for the process to complete, which means that
the initial gitk GUI will be unresponsive until the user quits the
gitk window showing the merge, which could be quite confusing for the
user.

Secondly, gitk already has support for showing multiple views of a
repository, that is, different subsets of the commits.  Wouldn't it be
much better to have your new menu item simply create a new view
showing the merge, rather than creating a whole new window?

Paul.

Re: [RFC/PATCH] gitk: Visualize a merge commit with a right-click in gitk

[Jason Holden]

On Mon, Dec 31, 2012 at 03:27:36PM +1100, Paul Mackerras wrote:
> 
> Thanks for the patch.  I have a couple of comments about it.  First,
> the exec command waits for the process to complete, which means that
> the initial gitk GUI will be unresponsive until the user quits the
> gitk window showing the merge, which could be quite confusing for the
> user.

Good catch.  Adding an ampersand on to the exec looks like it fixes
the unresponsiveness.  Any issues with that approach?

> 
> Secondly, gitk already has support for showing multiple views of a
> repository, that is, different subsets of the commits.  Wouldn't it be
> much better to have your new menu item simply create a new view
> showing the merge, rather than creating a whole new window?

I've found when using this feature that I tend to use it in a stack-like
fashion.  I tend to  want to "push" a merge-view onto the stack, investigate
that view of history for a bit, then "pop" back to my old view.  But 
you're correct that you can end up with a lot of windows pretty quick.  
Any support for stack-like views in the current gui that I missed?

I've got another feature brewing, similiar to the merge-view, where you can 
right-click on a file and a new window pops up with the history of just that 
file.  I tend to use that feature in a stack-like fashion as well.

Maybe the seperate-window/new-view-in-same-window should be a new user
preference?