Re: qgit idea: interface for cherry-picking

> "Marco Costalba" <mcostalba@gmail.com> writes:
>
>
> Yes, either you (1) need to make sure the user is aware what
> underlying git commands QGit runs for them, so that the user
> knows what workflow to follow when the procedure needs to go
> manual, or (2) hide the underlying git commands QGit runs for
> users, but then you need to make QGit aware of what workflow to
> follow when the procedure needs to go manual, and guide the user
> through that workflow.  I think either is fine approach;
> personally I prefer transparent tools that does (1), which is
> the impression I am getting from your description of QGit.
>

> If you take route (1), using "am --fail" number of times
> involves QGit runs "am --fail" once, guide user to fix things up
> _and_ give control back to QGit, then you run the next "am
> --fail", etc, which would be quite cumbersome to implement.  But
> running multiple am and do reset soft to roll back needed number
> of parents might be easier option to implement in QGit, but you
> still have the same "you give the control to the user but then
> you have to take the control away to proceed" problem when the
> patch does not apply cleanly somewhere (you let the user to hand
> resolve and say "am --resolved", but then when the series is
> depleted, somebody has to run "reset --soft" to roll N commits
> back to realize what you wanted to do, so at that point QGit
> somehow needs to take control back).
>
>