Hi Junio,
Junio C Hamano writes:
> Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes:
>>>> + if (!cur->next)
>>>> + /*
>>>> + * An error was encountered while
>>>> + * picking the last commit; the
>>>> + * sequencer state is useless now --
>>>> + * the user simply needs to resolve
>>>> + * the conflict and commit
>>>> + */
>>>> + remove_sequencer_state();
>>>> return res;
>>>> + }
>>>> }
>>>
>>> It may be useless for --continue, but wouldn't --abort need some clue on
>>> what you were doing?
>> ...
>> Conclusion: Making "git commit" remove the sequencer state is WRONG.
>
> Why not choose to not to clean it at all? Then "rebase --continue" and
> its equivalent to cherry-pick, rebase and any sequence command) can (and
> have to anyway) notice that there is nothing more to do, remove the state
> directory and state "there is nothing more to do".
1. Without this patch, some existing tests break.
2. There is nothing obviously wrong with the patch, and it even
enhances user experience. Have we paid a heavy price for not breaking
existing tests?
I could drop the patch and fix all the tests, but is that what we'd like to see?
-- Ram
��.n��������+%������w��{.n��������n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�