Subject: Re: [PATCH v1 09/19] rebase -i: commit only once when rewriting picks

From: Jeff King <[email-masked]>
Date: Fri, 1 Aug 2014 20:22:31 -0400

On Tue, Jul 29, 2014 at 01:18:09AM +0200, Fabian Ruch wrote:

> The options passed to `do_pick` determine whether the picked commit
> will be rewritten or not. If the commit gets rewritten, because the
> user requested to edit the commit message for instance, let
> `pick_one` merely apply the changes introduced by the commit and do
> not commit the resulting tree yet. If the commit is replayed as is,
> leave it to `pick_one` to recreate the commit (possibly by
> fast-forwarding the head). This makes it easier to combine git-commit
> options like `--edit` and `--amend` in `do_pick` because
> git-cherry-pick does not support `--amend`.
> 
> In the case of `--edit`, do not `exit_with_patch` but assign
> `rewrite` to pick the changes with `-n`. If the pick conflicts, no
> commit is created which we would have to amend when continuing the
> rebase. To complete the pick after the conflicts are resolved the
> user just resumes with `git rebase --continue`.

Hmm. So does this mean the user will actually see a different state
during such a conflict?

E.g., if I have instructions like:

  pick A
  squash B
  squash C

and there is a conflict picking C, then what state do I see? Right now I
see a commit with the A+B squash prepared. But your description sounds
to me like we would avoid the squash for "B", and the user would see a
different state.

However, I couldn't trigger that behavior in a few experiments. Am I
misunderstanding, or is there some case where the user-visible state
will be different?

-Peff