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

Reply via email to