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