Re: [egit-dev] Cherry pick workflow?

[Robin Rosenberg <robin.rosenberg@xxxxxxxxxx>]

10 nov 2010 kl. 20:39 skrev Christian Halstrick:

> Hi,
> 
>> I don't see how you could use the history view for this. For me it
>> would be more natural to add the remote, fetch the objects and then
>> open a 'Open Type' similar dialog to hunt for commits to cherry pick.
> 
> I would also prefer that I don't have to go to another view and can
> select an appropriate commit in a dialog. But, as Shawn said, that's a
> mainly a history view in a dialog. In the dialog version we could skip
> some of the data presented in history view (e.g. the diffs, affected
> files, etc) and simply filter the list more and more as you type a
> search phrase. Possibilities to show only commits which have refs
> (e.g. branches) pointing to them would help also. As fast way to
> select a commit I would like such a dialog.

I disagree. Dialogs are bad (tm). The issue with the history view is that
it's not good enough. A crippled dialog will not help. I need the information
in that the history view has to be able to pick the right commit, including
diffs, affected files, path filtering, grep etc. There is nothing a dialog
can do that a view cannot do, but the reverse is true.

Bad user interfaces have one thing in common: dialogs that enforce the one
and only approved workflow. Eclipse is mostly gpod because it is mostly based on 
views, rather than dialogs, allowing me to do things the way I want. 

All too often i open a dialog, start working just do discover that I need some
information and I have to close the dialogs, find what I want an go through the
dialogs again. Usually I can only pick one piece of information using the clipboard. 
With views I can do all kinds of fun things like copy/pasting from anywhere, do drag
and drop etc. Dialogs have one advantage only: they are easier to code.

Just add a menu with a hint about cherry-picking to the context menu if you
want to help newcomers.

-- robin