On 7/4/06, Junio C Hamano <junkio@xxxxxxx> wrote:
"Marco Costalba" <mcostalba@xxxxxxxxx> 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.
Yes, I prefer way (1) too. QGit as an error reporting infrastructure
to always report by a message box arguments (starting from 0) of
offending command, be it native git or not.
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).
I have started to implement the feature suggested by Jakub (patch in
working dir only, not committed). The core is a loop of git-am, one
for each patch to import, followed by a:
git-reset --mixed HEAD~<Num of succesfully applied patches>
To note that the above git-reset command is _always_ run be the patch
series apply successfully be it fails at some point, so that in any
case the tree is not dirty up, and you have the working tree with the
information you need in case of manual fixup.
I will plan to push as soon I'm able to reach a "pushable site" ;-)
Comments? could work? not consistent?
Marco
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html