1

In our repository we develop features based on feature branches. Lately I integrated a feature feature/myfeature into master:

git merge --no-ff feature/myfeature

After this merge some more development happened until it turned out, that this feature was faulty and blocked integration so I decided to revert this merge. Following https://stackoverflow.com/a/6217372/1237653 I choosed the only option to revert the merge without breaking the history:

git revert -m 1 commit_hash

Meanwhile even more development on masterhas happened as well as the author has added fixup commits. Now I want to go for a second run to integrate/merge the feature. Unfortunately now I get dozen of conflicts, because the first apply & revert touches the very same lines of code as it would the second try.

git merge --no-ff feature/myfeature
<pointless conflicts all over>

How can I reapply my previously reverted feature-branch without those pointless conflicts?

I tried -s recursive -Xrenormalize without luck. Rebase would cause the same conflicts, too.

Community
  • 1
  • 1
bentolor
  • 3,126
  • 2
  • 22
  • 33
  • As a "workaround" I destroyed the history of a feature-branch by manually cherry-picking all its commits into a new branch overwriting the old one. Feels bad & ugly. – bentolor Jun 21 '13 at 14:20

1 Answers1

0

Instead of merging a second time the branch you reverted, you should revert the revert commit. I mean literally,

git revert <sha1>

where sha1 is the commit made by your earlier git revert.

gcbenison
  • 11,723
  • 4
  • 44
  • 82
  • Thanks! I think this solution has some usability flaws, because after that I have to reapply/merge the feature branch a second time to catch the remaining changes. And if that fails again, then everything quadrupels... – bentolor Aug 27 '13 at 07:45