Re: [PATCH] Test that the 'rebase -i' "reword" command always cherry-picks a commit.

From: Avery Pennarun <apenwarr@gmail.com>
Date: Mar 22, 2010, 20:23 UTC
Message-ID: <32541b131003221323u1ed540bbi87d8d427cfcc421a@mail.gmail.com>
In-Reply-To: <1269285942-17496-1-git-send-email-marcnarc@xiplink.com>

On Mon, Mar 22, 2010 at 3:25 PM, Marc Branchaud <marcnarc@xiplink.com> wrote:

Show 28 quoted lines

> +Sometimes you're in a situation like this
> +
> + P---o---o---M---x---x---W---x
> +  \         /
> +   A---B---C
> +
> +where you:
> +
> + - Need to rewrite one of the commits on the A-B-C branch; and
> +
> + - Want the rewritten A-B-C branch to still start at commit P (perhaps P
> +   is a branching-off point for yet another branch, and you want be able to
> +   merge A-B-C into both branches).
> +
> +The natural thing to do in this case is to checkout the A-B-C branch and use
> +"rebase -i A" to change commit B.  However, this does not rewrite commit A,
> +and you end up with this:
> +
> + P---o---o---M---x---x---W---x
> +  \         /
> +   A---B---C   <-- old branch
> +   \
> +    B'---C'    <-- rewritten branch
> +
> +To merge A-B'-C' into the mainline branch you would still have to first revert
> +commit W in order to pick up the changes in A, but then it's likely that the
> +changes in B' will conflict with the original B changes re-introduced by the
> +reversion of W.

I think you need to clarify in the above text that W is a revert of M.
 I was very confused by this at first.

Other than that, I'll leave it to others more opinionated than me to comment on whether regenerating a commit just for the sake of regenerating it is actually desirable or not :)

Have fun,

Avery