1

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!

Sbodd
  • 11,279
  • 6
  • 41
  • 42
  • This might be useful: http://stackoverflow.com/questions/25886147/git-rebase-skip-merge-commits/25894618#25894618 – jub0bs Dec 01 '14 at 20:35
  • Try checking out a new branch from the head of 'child' and merging from master to your new branch. Then try a merge from the new branch back to master (or another local branch checked out from master) – kdopen Dec 01 '14 at 21:23
  • @Jubobs - that's basically what I wound up doing; I was just wondering if there was a way to make "merge" be smarter about what it did. – Sbodd Dec 02 '14 at 15:22
  • @kdopen - that didn't help; I still wound up with a bunch of (outdated) changes from the merge commits G and I showing up in my merged baseline – Sbodd Dec 02 '14 at 15:23
  • Is this a public repo (on github or similar)? You said everything had been pushed upstream. being able to look at it would help – kdopen Dec 02 '14 at 15:45
  • Alternatively, how many people share this repo? Rewriting history is painful, but if *everyone involved* knows it's going to happen and agrees, it can be managed. Finally, you can always use local rewriting to create a new branch which looks just right, push up that branch (with a distinct name) and when it's fully validated rename it to master (saving the old master with a different name). There's nothing special in git about that branch name :) – kdopen Dec 02 '14 at 15:52
  • Nope, it's non-public. Shared among a team of ~30. Though your comment leads me to ask - could I do a local rewrite (e.g. with a rebase) and then push in a manner that the server doesn't see a rewrite, just a bunch of new revisions? – Sbodd Dec 02 '14 at 16:55

0 Answers0