Re: flatten-merge history

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Oct 26, 2014 at 4:19 PM, Andreas Schwab <schwab@xxxxxxxxxxxxxx> wrote:
> Henning Moll <newsScott@xxxxxx> writes:
>
>> 1. For P, A is the nearest prior commit on 'master'
>> 2. on master: git rebase -i A^
>> 3. change A from pick to edit. save. quit
>> 4. git merge P
>> 5. git rebase --continue
>>
>> From the perspective of 'master' this worked. But as all of the commits
>> have been rewritten, the branches b1 and b2 no longer refer to
>> 'master'. Branch b2, for example, still branches off at B and not B'.
>
> You only rebased master, so b1 and b2 were unchanged.  If you want to
> change b1 and b2 you have to rebase them as well.

Yeah. Henning, when interactively rebasing, in our editor, you should
have something like:

pick A
pick P
pick B
pick Q
pick C
pick D
pick R
pick E

which should work without any conflict.
And then you can rebase the b1 and b2 branches on the resulting branch.

Best,
Christian.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]