Re: [PATCH REGRESSION] builtin/rebase: allow user to amend committed conflicts again

[Junio C Hamano <gitster@pobox.com>]

Elijah Newren <newren@gmail.com> writes:

> Longer term, I wonder whether plain "git commit" should be rejected
> while resolving conflicts for rebase, am, cherry-pick, and revert,
> with users directed to the corresponding "--continue" command.  Plain
> commit has a surprising collection of behaviors:
> ...
> workflow, but I think plain "git commit" should eventually be
> disallowed as a way to resolve conflicts for other commands.
>
> That's post-2.56 work.

I would say castrating "git commit" so that it can only do a plain
vanilla committing, while it may be a very good move from everything
you said above, is post-3.0, not post-2.56, work ;-).

> For now I think either reverting (and trying
> again after the release), or recording HEAD in stopped-head seems
> preferable to relying on MERGE_MSG.

Between the two I'd say giving us a chance for a clean start is far
more preferrable than repeating "Patrick thought of MERGE_MSG and
after a few hours Phillip and Elijah thought of a more robust new
mechanism.  Let's hope there is no more holes found in the newly
proposed mechanism in another few hours" after -rc2 got tagged.