Hello Johannes, W dniu 01.09.2016 o 10:01, Johannes Schindelin pisze: > On Wed, 31 Aug 2016, Jakub Narębski wrote: >> W dniu 31.08.2016 o 20:36, Johannes Schindelin pisze: >> >> I wonder: would 'git cherry-pick --continue' be able to finish >> 'git revert', and vice versa, then? Or 'git sequencer --continue'? > > I just tested this, via > > diff --git a/t/t3510-cherry-pick-sequence.sh > b/t/t3510-cherry-pick-sequence.sh > index 96c7640..085d8bc 100755 > --- a/t/t3510-cherry-pick-sequence.sh > +++ b/t/t3510-cherry-pick-sequence.sh > @@ -55,7 +55,7 @@ test_expect_success 'cherry-pick > mid-cherry-pick-sequence' ' > git checkout HEAD foo && > git cherry-pick base && > git cherry-pick picked && > - git cherry-pick --continue && > + git revert --continue && > git diff --exit-code anotherpick > > (Danger! Whitespace corrupted!!!) > > It appears that this passes now. I'm now not sure if it is such a great idea. As was said somewhere else in this thread, different sequencer-based commands sports different options, and you can add options to the "git <command> --continue". For example you can say "git cherry-pick --continue -x", but you cannot say "git revert --continue -x", as '-x' is a cherry-pick only option. Or you can, theoretically, use "git am --continue --no-3way". One option is to temporarily relax the test (test_expect_failure), then fix it at the end. BTW. how git-am uses sequencer? I have seen "revert" etc., and "pick" etc., but no git-am related constants or strings... > Probably `git sequencer --continue` would work, too, if there was a `git > sequencer`. :0) Right. > >>> On Wed, 31 Aug 2016, Jakub Narębski wrote: >>>> W dniu 29.08.2016 o 10:04, Johannes Schindelin pisze: >> >>>>> diff --git a/t/t3510-cherry-pick-sequence.sh b/t/t3510-cherry-pick-sequence.sh >>>>> index 7b7a89d..6465edf 100755 >>>>> --- a/t/t3510-cherry-pick-sequence.sh >>>>> +++ b/t/t3510-cherry-pick-sequence.sh >>>>> @@ -459,17 +459,6 @@ test_expect_success 'malformed instruction sheet 1' ' >>>>> test_expect_code 128 git cherry-pick --continue >>>>> ' >>>>> >>>>> -test_expect_success 'malformed instruction sheet 2' ' >>>> >>>> Hmmm... the description is somewhat lacking (especially compared to >>>> the rest of test), anyway. >>>> >>>> BTW. we should probably rename 'malformed instruction sheet 2' >>>> to 'malformed instruction sheet' if there are no further such >>>> tests after this removal, isn't it? >>> >>> No, we cannot rename it after this patch because the patch removes it ;-) >>> (It is not a file name but really a label for a test case.) >> >> Ooops. What I wanted to say that after removing the test case named >> 'malformed instruction sheet 2' we should also rename *earlier* test >> case from 'malformed instruction sheet 1' to 'malformed instruction sheet', >> as it is now the only 'malformed instruction sheet *' test case. > > Actually, you know, I completely missed the fact that there was a > "malformed instruction sheet 3". I renumbered it. Ooops. I have missed it too, having looked only at the test after the one removed (which is not about malformed instruction sheet). Best, -- Jakub Narębski