So, I've got a scenario that looks about like the following:
A----B----C----D (master)
\ \ \
E-F--G--H-I (child)
C and D in this case represents huge sets of changes, including lots of rearranging of directory trees. F and H are much smaller, and generally limited to contents of files. The individual files in F and H haven't changed much in B, C, or D. All of these revisions exist in a shared upstream repository (so anything that edits history is out, as I understand it).
What's the easiest can I end up with a branch that contains A, B, C, D, F, and H?
Doing git checkout master; git merge child ends up reverting a large amount of the structural changes made in C and D, I'm assuming because it's picking up the changes from the merge commits G and I. (Lots of the files that were relocated in C and D end up in the working tree twice.)
I can do a cherry-pick on F and H (though in my example, they represent about a dozen commits - enough to be annoying).
Ideally what I'd like would be a git merge --ignore-merge-commits option.
I don't think I can rebase child onto D, because E-I are all already in a shared repo.
Any other suggestions, or should I just go cherry picking?
Thanks!