On 7/3/06, Junio C Hamano <junkio@xxxxxxx> wrote:
If you had a series of patches chosen inside your GUI and
squash-apply them all, two full am with soft reset to the
original state would be the easiest, if and only if both patch
applications do not fail. If patch A does not apply for
whatever reason, you have to guide your user through the patch
adjustment process before applying B, regardless of the reason
why the patch application failed (either A did not apply
cleanly, or you gave --fail to the command).
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'.
So in case a patch does not apply a message feedback is returned and
the process is terminated. All the not qgit generated intermediate
files are left at their places and is up to the user fix the things
up, possibly using native git commands.
QGit does not play magic. If something goes wrong it simply stops.
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