[RFC/PATCH] gitk: Visualize a merge commit with a right-click in gitk
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.sw...@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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Add MAINTAINERS file and clarify gui workflows
I spent a good amount of time yesterday figuring out the correct workflow to submit a change to gitk. As I understand it, gitk (and I think git-gui) are maintained upstream of git, and patches should be sent to the git email list against the upstream repo. I think a top-level MAINTAINERS file would help new contributers like me get orientated, especially in the cases of these upstream projects that require a somewhat non-standard workflow I also added some additional clarifications to SubmittingPatches that clarifies the additional steps required to submit patches against the guis. Please double check that I've got the correct email addresses and canonical repositories I'm guessing there are additional Maintainers who should be added to the MAINTAINERS file, I just haven't followed to email list closely enough to know all the formal/informal workflows that should be observed. Jason Holden (2): Add top-level maintainers file with email/canonical repository information Provide better guidance for submitting patches against git-gui, gitk Documentation/SubmittingPatches | 11 +++ MAINTAINERS | 17 + 2 files changed, 28 insertions(+) create mode 100644 MAINTAINERS -- 1.8.1.rc3.28.g0ab5d1f -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Add MAINTAINERS file and clarify gui workflows
On Mon, Dec 31, 2012 at 09:40:19AM +, Thomas Ackermann wrote: Junio C Hamano gitster at pobox.com writes: Thanks; I just realized that nothing in Documentation/ hierarchy mentions these; they are only mentioned in A Note from the Maintainer I send out every once in a while (kept in MaintNotes of 'todo' branch): Wouldn't it be a good idea to put MaintNotes somewhere below ./Documentation? --- Thomas Putting it in Documentation/ would add one more outlier file (Along w/ SubmittingPatches and CodingGuidelines). Documentation/technical seems too deep. I've got a patch that incorporates the content into the existing README, but that seems a bit out of place, as the previous content of README was primarily pointers to other docs. What about a README.developers at the toplevel? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] gitk: Visualize a merge commit with a right-click in gitk
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? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Bug in latest gitk - can't click lines connecting commits
I was testing some patches against the latest gitk, and noticed that when I click the mouse on the lines that connect the commits in the history graph, I get an error popup with: Error: can't read cflist_top: no such variable Looks like this was introduced in gitk commit b967135d89e8d8461d059 gitk: Synchronize highlighting in file view when scrolling diff This commit hasn't been merged yet from upstream into git. Here's the full error trace: can't read cflist_top: no such variable can't read cflist_top: no such variable while executing $cflist tag remove highlight $cflist_top.0 $cflist_top.0 lineend (procedure highlightfile line 4) invoked from within highlightfile 0 (procedure highlightfile_for_scrollpos line 8) invoked from within highlightfile_for_scrollpos $topidx (procedure scrolltext line 9) invoked from within scrolltext 0.0 1.0 (vertical scrolling command executed by text) -Jason -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] SubmittingPatches: mention subsystems with dedicated repositories
On Tue, Jan 01, 2013 at 03:24:54PM -0800, Junio C Hamano wrote: +Subsystems with dedicated maintainers + +Some parts of the system have dedicated maintainers with their own +repositories. + + - git-gui/ comes from git-gui project, maintained by Pat Thoyts: + +git://repo.or.cz/git-gui.git + + - gitk-git/ comes from Paul Mackerras's gitk project: + +git://ozlabs.org/~paulus/gitk + + - po/ comes from the localization coordinator, Jiang Xin: + + https://github.com/git-l10n/git-po/ + +Patches to these parts should be based on their trees. + + An ideal patch flow Any reason to leave out the maintainers email addresses? If we add that, all the content of the MAINTAINERS file we had been discussing would then be in this file. My only other suggestion for this series might be to augment the file with a patch submittal example(s). I found the best example to be in git-send-email's man page, but maybe enumerate the example out for the most common workflows. Maybe something like: --- Example of sending patches for a new feature: Create the patches: $ git format-patch --cover-letter -M origin/master -o outgoing/ $ edit outgoing/-* To send your completed patches for initial consideration: $ git send-email outgoing/* -to git@vger.kernel.org -cc gits...@pobox.com To send your reviewed patches for inclusion: $ git send-email outgoing/* -to gits...@pobox.com -cc git@vger.kernel.org -Jason -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
