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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html