Re: qgit idea: interface for cherry-picking

[Junio C Hamano <junkio@cox.net>]

"Marco Costalba" <mcostalba@gmail.com> writes:

>> The main question is what you would let your users do and how
>> you would guide them through the process, when the application
>> of an earlier patch in the series fails.  I think it is a
>> secondary implementation detail which of "git-am", "git-am
>> --fail" or "git-apply" to implement that process.
>
> QGit is not supposed to be a GUI replacement of git UI. QGit only let
> users quickly call some commonly used commands. The process of error
> recovering, conflicts resolve and any other complication that could
> involve more the one main flow of processing are outside the scope.
> QGit simply leaves the job to native git tools any time there
> something 'outside tha main flow'.

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