Alan Chandler <alan@xxxxxxxxxxxxxxxxxxxxx> writes:
> 2' - 2a - 3' - 4' ----------------- 6' SITE
> / / / /
> 1 - 2 ------ 3 - 4 ------------6'''- 6a TEST
> \ /
> 5 ------ 6 MASTER
> \ \
> 5''- 5a- 6'' DEMO
>
>
> What will happen is the changes made in 4->5 will get applied to the
> (now) Test branch as part of the 6->6'' merge, and I will be left
> having to add a new commit, 6a, to undo them all again. Given this is
> likely to be quite a substantial change I want to try and avoid it if
> possible.
I presume 6'''-6a has the revert of 4-5? If so, the next merge should
work just fine.
You have arranged TEST->SITE transition correctly to limiting the SITE
customization to 2a and never merging SITE back to TEST, so we can ignore
SITE branch altogether from now on. Similarly we can ignore DEMO branch,
since its customization is limited to 5a and it never gets merged back to
MASTER.
1 - 2 ------ 3 - 4 ------------6'''- 6a-----7a??? TEST
\ / /
5 ------ 6------------7 MASTER
Now, 6-7 is a new feature built on MASTER. What would happen when it is
merged to TEST to produce 7a?
The merge base for this merge is 6, and since that commit to the tip of
the TEST branch 6a, there is a "skin from vanilla to FanClub" change and
nothing else. On the other hand, since the merge base to the tip of the
MASTER branch 7, there is a "feature enhancement" but no skin related
changes.
So bog-standard three-way merge should say:
- One branch, MASTER, added these features, but TEST branch did not do
anything with these feature changes since the merge base. We'll use
the feature change done on MASTER.
- The other branch, TEST, changed the skin from the merge base, but
MASTER branch did not change any skinning. We'll keep the skin change
done on TEST.
And everything should be fine.
--
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