0

Sequence:

  1. commit some code on trunk
  2. discover that it's got a nasty problem.
  3. make a branch
  4. delete code on trunk (deleting entire files)
  5. fix code on branch

Now I want to bring the whole business back onto the trunk. A merge won't do it, I think. What will?

Cascabel
  • 479,068
  • 72
  • 370
  • 318
bmargulies
  • 97,814
  • 39
  • 186
  • 310

2 Answers2

1

Assuming there's no git-svn craziness here (I'm not sure if your use of the word "trunk" means you came from svn and kept terminology, or are actually interacting with it)...

The cleanest way to do this, assuming your "delete code on trunk" triage step was done in an isolated commit, is to revert that commit, then merge:

git checkout master
git revert <triage-commit>     # could do this for multiple commits if needed
git merge bugfix-branch

If it's not that clean, merging is the way to go; you'll just have to handle some things. You might want to do it on a test branch just in case:

# start back from master
git checkout -b master-merge master
# merge your fixes
git merge bugfix-branch

At this point, you should run into a lot of "deleted by us" conflicts (that's how they're reported by git status). This indicates that they were deleted on "our" branch (master) but modified on the to-be-merged branch. It will leave the versions from the to-be-merged branch in the tree. You can git add them to mark them as resolved. If you have conflicts that aren't of this form, you'll have to work through them as usual. Once you've fixed it all, inspect the results, test, and git commit to complete the merge.

If you're confident that all conflicts will result from this triage/bugfix scenario, then you could have used git merge -X theirs to tell Git to resolve all conflicts by keeping "their" version (the one from the bugfix branch). Only do this if you're sure!

git-svn note: I've heard that git-svn has issues with merges. I've never used it, I have no idea how it works, but if it's the case that you're not supposed to have merges in anything you intend to send back to the svn repo... then instead of merging above, you could rebase git rebase master bugfix-branch. You'll run into exactly the same merge conflicts. Once you've dealt with them, you can fast-forward master up to the newly-transplanted branch with git checkout master; git merge bugfix-branch.

Cascabel
  • 479,068
  • 72
  • 370
  • 318
0

In git you can just use rebase if you have not already pushed the changes. (And you usually branch before making a commit, to test it first before commission: 1. make branch, 2. commit, 3. test, 4. push, 5. let others test, 6. merge to master if it looks ok to everybody.)

jørgensen
  • 10,149
  • 2
  • 20
  • 27