I'm merging upstream changes to my project, and recently there were a lot of commits that created a lot of merge conflicts. It doesn't make sense to try to resolve them all at once.
How can I find out which commits create a conflict? Any of the following are acceptable:
- A way to make Git stop merging as soon as it finds a conflict
- A way to make Git list all the commits that conflicted, in chronological order
- Anything else that lets me resolve the conflicts one-by-one, in chronological order, that doesn't involve merging a few commits at a time hoping to stumble upon the conflicts
You can gives git imerge a try: that will apply your commits one by one, giving you the chance to do a rebase incrementally (meaning you can start a rebase, interrupt it, resume it later!).
You can see here a comparison between Incremental merge vs. direct merge vs. rebase.
Michael Haggerty also has a tool called git-mergemate that has a find-conflict command:
git-mergemate find-conflict BRANCH1..BRANCH2
Use bisection to determine the earliest commit on BRANCH2 that
causes a conflict when merged to BRANCH1. Don't actually
retain any merges.
git-mergemate find-conflict BRANCH1...BRANCH2
Use bisection to find a pair of earliest commits (one from
each branch) that do not merge cleanly. Don't actually retain
any merges.
git imerge can be used to do an incremental merge and resolve conflicts along the way, though it does not have the equivalent of find-conflicts in git-mergemate.
Is there any reason why you wouldn't just want to use rebase (non-interactively) to sync up with changes in the upstream branch? It will stop if there is a conflict on each commit, and then you can resume the rebase when it's resolved. It's like incremental merging, and it's built right into Git, there's no need for an external plugin/tool:
git fetch <remote>
git rebase <remote>/<upstream-branch>
# Conflict on commit X, resolve conflict, then continue the rebase
git rebase --continue
Warning about force pushing rewritten commits
Note, of course, that rebasing your local branch will change the sha IDs of its commits. If you've already pushed the commits that you want to rebase to your remote, then you'll need to force push the new commits to overwrite the old ones, which might pose a potential problem if you're sharing your branch with other people. You can learn more about these problems in:
- Pro Git § 3.6 Git Branching - Rebasing - The Perils of Rebasing
