Re: [PATCH 7/7] sequencer: Remove sequencer state after final commit

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 18, 2011, 20:22 UTC
Message-ID: <7v8vqqa2qu.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CALkWK0=jRAq6s1zQ5gwB4feBgC1eo=VYLWx8bsjs+exqmz0f1A@mail.gmail.com>

Ramkumar Ramachandra <artagnon@gmail.com> writes:

>> Why modify tests?  I think "git merge --continue" is a nice idea,
>> and I don't see how it's inconsistent in any way with continuing to
>> allow old practice.

I agree. Updating the test will hide a regression if Ram's update breaks the existing workflow to conclude a conflicted merge with "git commit". If we are to add "git merge --continue" sugarcoat to make it easier to teach new people saying that "To any Git operation that stops and asks you to help, you can tell it that you are done helping by re-running the same command with --continue flag", then _new_ tests should be added to make sure that "git merge --continue" does act just like "git commit" in such a case.

> In the future, we might want a 'merge' instruction in the sequencer --

The end-user facing frontend may be "git rebase" in such a case, and we would be teaching the users "When you are done helping the conflicted 'rebase', tell it that you are done by running 'rebase --continue'". The command verb 'merge' on the sequencer insn sheet does not have any direct connection to 'git merge' command (e.g. 'pick' does not have to be and is not implemented using 'git pick' command that does not exist). So I do not think we would ever say "merge --continue" in this context to begin with.

Show 9 quoted lines

>> As Junio hinted, it could make a lot of sense for "git cherry-pick
>> <single commit>" to not create sequencer state in the first place.
>> "git cherry-pick --continue" does not need it --- it is enough to
>> commit with the conflict resolved.  "git cherry-pick --abort" does not
>> need it, either --- it is enough to "git reset --merge HEAD".
>
> Okay, here's my problem with the idea: it'll essentially require the
> sequencer to differentiate between one-commit operations and
> many-commit operations.

I think you are looking at it in a wrong way. It is just about giving
backward compatibility to historical hacks. cherry-pick and revert may be
the only ones needed, and a new command Foo that implements its workflow
in terms of the sequencer can choose to (and should choose to unless there
is a compelling reason not to, because of the exact reason you stated
here) do a single-command insn sheet with "git Foo --continue" to conclude
if that one and only step needed help from the end user.
 
"git am" would fit in the picture the same way. The sequencer insn sheet
it would produce would consist of "patch <filename>" or something, and
after the last one of them fails, the user would fix things up in the
working tree, "git am --continue" will create a commit, and because there
is no more steps in the sequence, the sequencer state will be removed.