1

First, I have studied this answer but it doesn't quite match my situation. We currently have this:

---o---o---C---M---W  <-- develop
              /
      ---A---B        <-- new_feature

When I tried to merge B with C (git checkout develop && git merge new_feature), there was a bunch of conflicts that I fixed, and pushed M as the result. The person who wrote C was testing, and found that my merge M had lost some of his changes, so he did a git revert M to get W, which code-wise is identical to C. Now, I have been asked to try again, but as mentioned in the linked answer, the history includes a flag to say that new_feature has been merged so trying to repeat git merge B gives me the message:

Already up-to-date.

Doing a reset is going to confuse all our downstream CI processes, so I cannot do that. There's four commits in the new_feature branch, so is a cherry-pick my best option, but I'm not sure if cherry-picking multiple commits is equivalent to merging a branch. Or is git revert --no-commit W then manually checking where the changes in C went the easiest option?

Ken Y-N
  • 14,644
  • 21
  • 71
  • 114
  • 1
    See [this answer](https://stackoverflow.com/a/57905240/6868543). – j6t Dec 06 '19 at 06:28
  • That's interesting, and might even be a dup of this question. I ended up doing the `git revert --no-commit W`, though, and fortunately it was only one file that had messed up its merge. – Ken Y-N Dec 06 '19 at 07:20

0 Answers0