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
