Re: [PATCH] commit: refuse to amend during conflict resolution

> ...  However, with the merge backend of rebase we have to
> be more careful, since it powers interactive rebases and
>   - the interactive machinery internally uses `git commit --amend` for
>     `squash` and `reword` directives
>   - users are expected to `git commit --amend` after hitting an `edit`
>     or `break` directive
> So, we need to be careful with rebase to only reject amending when doing
> conflict resolution.

> A few files under the rebase-merge/ directory provide us the necessary
> information:
>
>   - stopped-sha is written only when the rebase stops and hands control
>     back to the user, so its presence marks a genuine stop -- as opposed
>     to the sequencer's own internal `git commit --amend` while applying
>     a squash, fixup, or reword, during which no stopped-sha exists.
>
>   - amend is written only when the rebase stops with HEAD already
>     pointing at the commit the user is meant to amend: a clean `edit`,
>     or a fast-forward `reword`.  Its absence at a stop therefore means
>     the commit did not apply, so HEAD is the previously-applied commit
>     rather than the one being rebased -- exactly the case we refuse.
>
> So for the merge backend we die when stopped-sha exists and amend does
> not.  This covers a plain conflicted pick as well as a conflicted `edit`
> (both leave HEAD on the previously-applied commit), while still allowing
> a clean `edit` or `reword` stop and a `break` stop (no stopped-sha).
> stopped-sha is unlinked at the start of the resume loop, so a resumed
> squash's internal amend is unaffected.