2

(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?

Mark Chimes
  • 295
  • 1
  • 11
  • Why not just copy the repo into a different directory, and run beyond compare in the copy directory, reading its recommendations and manually applying them in the original directory using your IDE? – Stun Brick Jul 17 '18 at 09:52
  • 1
    The repo is a bit big, but that gives me an idea. EDIT: See my answer below. – Mark Chimes Jul 17 '18 at 09:59

2 Answers2

1

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.

Mark Chimes
  • 295
  • 1
  • 11
1

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".

lodewykk
  • 297
  • 2
  • 6
  • 1
    Why would you specifically open up their's instead of mine? – Mark Chimes Jul 17 '18 at 10:20
  • To clarify, my change was to move some functions out of this file into another. Their changes were to change things inside the functions. In this specific instance, I need to apply their changes to a completely different file to the one that they actually changed. In general, though, whether to take "theirs" or "mine" would surely depend on the context? – Mark Chimes Jul 17 '18 at 10:22
  • 2
    @MarkChimes, THEIRS, since I'm assuming you know best how to introduce your changes. It could work just as well using MINE. Really, ideally you'd choose the base which includes the most changes. EDIT: But yes, it's probably best to start with your refactored MINE in your case. – lodewykk Jul 17 '18 at 10:35