{"thread":{"id":"32476","subject":"[RFC/PATCH] gitk: Visualize a merge commit with a right-click in gitk","startedAt":"2012-12-30T00:16:16Z","lastAt":"2012-12-31T18:46:11Z","messageCount":3,"participants":["Jason Holden","Paul Mackerras"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"205664","messageId":"1356826576-24334-1-git-send-email-jason.k.holden.swdev@gmail.com","threadId":"32476","inReplyTo":null,"subject":"[RFC/PATCH] gitk: Visualize a merge commit with a right-click in gitk","fromName":"Jason Holden","fromEmail":"jason.k.holden.swdev@gmail.com","sentAt":"2012-12-30T00:16:16Z","receivedAt":"2012-12-30T00:16:16Z","isPatch":true,"sender":{"key":"jason.k.holden.swdev@gmail.com","avatar":null},"body":"When first doing a merge in git-gui, the \"Visualize Merge\" button is\nquite helpful to visualize the changes due to a merge.\nBut once the merge is complete, there's not a similarly convenient\nway to recreate that merge view in gitk.\n\nThis commit adds to gitk the ability to right-click on a merge commit and\nbring up a new gitk window displaying only those commits involved in\nthe merge.\n\nWhen right-clicking on a non-merge commit, this option is grayed out.  This\npatch also supports correct visualization of octopus merges\n\nSigned-off-by: Jason Holden <jason.k.holden.swdev@gmail.com>\n---\n gitk | 33 +++++++++++++++++++++++++++++++++\n 1 file changed, 33 insertions(+)\n\ndiff --git a/gitk b/gitk\nindex 379582a..17e1fcb 100755\n--- a/gitk\n+++ b/gitk\n@@ -2551,6 +2551,7 @@ proc makewindow {} {\n \t{mc \"Compare with marked commit\" command compare_commits}\n \t{mc \"Diff this -> marked commit\" command {diffvsmark 0}}\n \t{mc \"Diff marked commit -> this\" command {diffvsmark 1}}\n+\t{mc \"Visualize this merge\" command visualize_merge}\n     }\n     $rowctxmenu configure -tearoff 0\n \n@@ -2590,6 +2591,31 @@ proc makewindow {} {\n     $diff_menu configure -tearoff 0\n }\n \n+# Return the number of parents for a given sha1 id\n+proc get_numparents_from_id {id} {\n+    global parentlist\n+    set row [rowofcommit $id]\n+    return [llength [lindex $parentlist $row]]\n+}\n+\n+proc visualize_merge {} {\n+    global parents currentid parentlist\n+    global rowmenuid\n+\n+    set num_parents [get_numparents_from_id $rowmenuid]\n+    set row [rowofcommit $rowmenuid]\n+\n+    if {$num_parents >= 2} {\n+\tset revlist $rowmenuid\n+\tfor { set i 1 } {$i < $num_parents} {incr i} {\n+\n+\t    set revlist \"$revlist [lindex $parentlist $row 0]..[lindex $parentlist $row $i] $rowmenuid\"\n+\t}\n+\t\n+\teval exec gitk $revlist\n+    }\n+}\n+\n # Windows sends all mouse wheel events to the current focused window, not\n # the one where the mouse hovers, so bind those events here and redirect\n # to the correct window\n@@ -8577,6 +8603,13 @@ proc rowmenu {x y id} {\n \t$menu entryconfigure 9 -state $mstate\n \t$menu entryconfigure 10 -state $mstate\n \t$menu entryconfigure 11 -state $mstate\n+\n+\t# Disable visualize-merge on only one parent\n+\tif {[get_numparents_from_id $id] == 1} {\n+\t    $menu entryconfigure 15 -state disabled\n+\t} else {\n+\t    $menu entryconfigure 15 -state normal\n+\t}\n     } else {\n \tset menu $fakerowmenu\n     }\n-- \n1.8.1.rc3.28.g0ab5d1f\n"},{"id":"205691","messageId":"20121231042736.GA14921@iris.ozlabs.ibm.com","threadId":"32476","inReplyTo":"1356826576-24334-1-git-send-email-jason.k.holden.swdev@gmail.com","subject":"Re: [RFC/PATCH] gitk: Visualize a merge commit with a right-click in gitk","fromName":"Paul Mackerras","fromEmail":"paulus@samba.org","sentAt":"2012-12-31T04:27:36Z","receivedAt":"2012-12-31T04:27:36Z","isPatch":true,"sender":{"key":"paulus@samba.org","avatar":"https://avatars.githubusercontent.com/u/1606439?v=4"},"body":"On Sat, Dec 29, 2012 at 07:16:16PM -0500, Jason Holden wrote:\n\n> When first doing a merge in git-gui, the \"Visualize Merge\" button is\n> quite helpful to visualize the changes due to a merge.\n> But once the merge is complete, there's not a similarly convenient\n> way to recreate that merge view in gitk.\n> \n> This commit adds to gitk the ability to right-click on a merge commit and\n> bring up a new gitk window displaying only those commits involved in\n> the merge.\n> \n> When right-clicking on a non-merge commit, this option is grayed out.  This\n> patch also supports correct visualization of octopus merges\n\nThanks for the patch.  I have a couple of comments about it.  First,\nthe exec command waits for the process to complete, which means that\nthe initial gitk GUI will be unresponsive until the user quits the\ngitk window showing the merge, which could be quite confusing for the\nuser.\n\nSecondly, gitk already has support for showing multiple views of a\nrepository, that is, different subsets of the commits.  Wouldn't it be\nmuch better to have your new menu item simply create a new view\nshowing the merge, rather than creating a whole new window?\n\nPaul.\n"},{"id":"205703","messageId":"20121231184611.GB8665@gmail.com","threadId":"32476","inReplyTo":"20121231042736.GA14921@iris.ozlabs.ibm.com","subject":"Re: [RFC/PATCH] gitk: Visualize a merge commit with a right-click in gitk","fromName":"Jason Holden","fromEmail":"jason.k.holden.swdev@gmail.com","sentAt":"2012-12-31T18:46:11Z","receivedAt":"2012-12-31T18:46:11Z","isPatch":true,"sender":{"key":"jason.k.holden.swdev@gmail.com","avatar":null},"body":"On Mon, Dec 31, 2012 at 03:27:36PM +1100, Paul Mackerras wrote:\n> \n> Thanks for the patch.  I have a couple of comments about it.  First,\n> the exec command waits for the process to complete, which means that\n> the initial gitk GUI will be unresponsive until the user quits the\n> gitk window showing the merge, which could be quite confusing for the\n> user.\n\nGood catch.  Adding an ampersand on to the exec looks like it fixes\nthe unresponsiveness.  Any issues with that approach?\n\n> \n> Secondly, gitk already has support for showing multiple views of a\n> repository, that is, different subsets of the commits.  Wouldn't it be\n> much better to have your new menu item simply create a new view\n> showing the merge, rather than creating a whole new window?\n\nI've found when using this feature that I tend to use it in a stack-like\nfashion.  I tend to  want to \"push\" a merge-view onto the stack, investigate\nthat view of history for a bit, then \"pop\" back to my old view.  But \nyou're correct that you can end up with a lot of windows pretty quick.  \nAny support for stack-like views in the current gui that I missed?\n\nI've got another feature brewing, similiar to the merge-view, where you can \nright-click on a file and a new window pops up with the history of just that \nfile.  I tend to use that feature in a stack-like fashion as well.\n\nMaybe the seperate-window/new-view-in-same-window should be a new user\npreference?\n"}]}