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

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

"Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com> writes:

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

True.

In addition, in any and all of these scenarios that lets the user
deal with conflicts in his or her working tree files and record the
result of conflict resolution in a commit, we should reject not only
"git commit --amend" but also "git commit <paths>", shouldn't we?

It may probably be better done in a separate topic, as the guiding
principle is slightly different (i.e., "recording the conflict
resolution is about recording the state on top of the current HEAD
and never about updating the state recorded in the current HEAD" is
the theme of the current topic.  "recording the conflict resolution
is always about the entire tree" is the other topic), so we may want
to leave a #leftoverbits marker here.

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

That is a sound reasoning.  Nice.

> Signed-off-by: Elijah Newren <newren@gmail.com>
> ---