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