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

From: Jeff King <peff@peff.net>
Date: Aug 2, 2014, 00:22 UTC
Message-ID: <20140802002231.GD20040@peff.net>
In-Reply-To: <235b55a0ec3db4a111fbb32e58e578ced6307d72.1406589435.git.bafain@gmail.com>

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

Show 15 quoted lines

> 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