Resolving Merge Conflict in IDE Whilst Retaining 3-Way Merge Info

1k Views Asked by At

(I am using SourceTree as my Git tool, Beyond Compare to resolve merge conflicts, and Eclipse as my Java IDE.)

The conflict is complex enough that I cannot solve it in the merge tool, and will have to resolve it manually (across multiple files).

Ideally, I'd like to just take my version of the code, look at the conflicts in Beyond Compare, and use that to advise my changes in Eclipse.

Things that don't work:

  1. If I just open up the conflicting version in Eclipse, then the code doesn't compile, so I lose all of the usefulness of static type checking etc.
  2. If I just "resolve using ours/mine" in Git (SourceTree) so that I can open it in Eclipse, then I lose all of the nice three-way merge information that I could have used to resolve the conflict.
  3. Doing a naive diff of the HEAD version of the file with the master version does not solve my problem either - the diff has too little information. I want to have the three-way info.

Am I approaching this the wrong way? Should I be using a different strategy to resolve conflicts? Is there perhaps a feature of Git or BC4 that I could use to keep the conflict info separately whilst editing a specific version of the file?

2

There are 2 best solutions below

0
On BEST ANSWER

Something I've found that works (inspired by Stun Brick's suggestion):

Start the merge, so that the LOCAL, BASE, and REMOTE files are generated.

Move these files out to a separate directory.

Resolve the merge by taking the local copy (In SourceTree: Resolve Conflicts -> Resolve Using Mine. In Git: git checkout --ours PATH/FILE).

Open the local version of the file in Eclipse.

Open the LOCAL, BASE, and REMOTE files in BC4.

Now I can edit in Eclipse to my heart's content without affecting what BC4 displays.

3
On

Personally, I would copy the THEIRS version into Eclipse and re-introduce the local changes from there. If your MINE includes significantly more changes, or refactors a lot of code, it might be better to start with that.

This could be done this way:

  1. Open the in-progress merge files in Eclipse (with it's silly merge tags)
  2. View the THEIRS commit in Eclipse, (using a git plugin),
  3. Open the specific commit's version of the files (no merge tags)
  4. Copying everything over.
  5. Open the MINE commit's version as well and re-introduce your changes, manually continuing the merge.

This should allow you to start with a working MINE or THEIRS, adding to it piece by piece.

This would allow you to still use suggestions from BC for the most significantly changed file. Since git only opens the external merge for one folder at a time you'd have to manually open the other files in BC if you feel you need that.

You can then manually mark each file as "resolved".