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

[Marc Branchaud <marcnarc@xiplink.com>]

Avery Pennarun wrote:
> On Mon, Mar 22, 2010 at 3:25 PM, Marc Branchaud <marcnarc@xiplink.com> wrote:
>> +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.

Someone who reads through the whole file will see that W is the reversion of
M.  It's probably good to repeat that in the addendum for readers who jump to
the addendum right away.

> 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 :)

I'm all ears!

		M.