A merge unit is a whole set of changes, so C and D had to be done in smaller parts. Now you can merge all this and return some files, but this will lead to the fact that you will not be able to merge the rest later - they are already considered merged.
What I would do is make a branch parallel to the CD embedded in B in your example, which contains copies of the changes in C and D, but splits them into consecutive parts. You can then merge the whole changes with it and close (or perhaps even delete) the original CD branch.
C
In the above example, C1 and C2 together are equivalent to C. While I was on it, I went ahead and reordered four new change sets (use a rewrite history tool such as rebase ) so that you can then simply merge D1 with E:
C
If reordering new changesets is not an option, you will need to do some fancy branches to do partial revisions in the order of C1, D1, C2, D2; there are probably far fewer problems using graft (or transplant ) to copy changes that you are not allowed to merge separately. For example, in the future you can still combine C1, but then you need a copy of D1 (denoted by D1 '), since there is no way to combine it without pulling C2 along with it.
C
source share