Thread (6 messages) flat view 6 messages, 3 authors, 2016-06-15

Re: qgit idea: interface for cherry-picking

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:42:32

"Marco Costalba" [off-list ref] writes:
I cannot test your patch now, so I'm just guessing, what if we have a
series of patches?
The patch stops at each patch.  I am primarily interested in
keeping "git-am" usable from command line while making it easy
to use from other tools.

The expected use for the patch you are responding to is that
after the first application with --fail the user has an
opportunity to fix the result up but needs to create a commit by
rerunning "git-am" (or just drop that by resetting the index and
saying "git-am --skip").
Is it possible that for two patches A and B happens that

git-am A
git-am B
git-reset --soft HEAD^^

gives a different result then

git-am --fail A
git-am --fail B
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help