• Eclipse Git Merge
• Best Eclipse Plugins

Figure 2: Initial history view Now, assuming you have chosen alternate approach to the Core and UI bugs, there are at least four (4) different ways to merge. (If you have other ideas on how to merge these branches, please leave a comment). Merge Tool For those of you new to git, the most intuitive way to merge these branches is to use the merge tool.

Sep 3, 2010 - Fortunately, I ran across a plugin that allows you to specify an alternate diff tool. It does not replace your existing Eclipse 'Compare With' menu but adds an additional menu for performing diffs via an external tool. The Eclipse plugin 'External diff Tool' allows you to launch an external diff tool for comparing.

You checkout the master branch and merge the newidea branch. Since the same functionality was implemented in two different ways, you are almost guaranteed to have merge conflicts.

Figure 4: Merged history view Once you have successfully resolved the merge conflicts, added the affected file to the git index and committed, your history view should look something like Figure 4. You can also cherry pick commits. For example, if you only want the alternate UI fix (commit G), but not the alternate core fix (commit F), you can cherry pick commit G.

Reset your Master Branch Since git is a with pointers (or references) to the tip of the branches, you can manipulate this graph. If you checkout the master branch and then issue a hard reset to the newidea branch (in the history view, right click on the newidea branch and selected Reset-Hard), the master branch will now point to the tip of the newidea branch. You have essentially tried two different ways to implement the same functionality, and when finished, you choose the second approach. However, you will not only lose the UI and Core fixes, but you will also lose the new security feature that you added (commit C, D and E). In this case, it’s important that you rebase your newidea branch off commit C first. Figure 5: Reset your master branch Once completed, your history view should look something like Figure 5.

Note: you should never attempt to reset branches like this if you’ve shared your repository. If anybody else has worked on the master branch, you will cause them (and likely you) a lot of headaches. This should only be used on private repositories, before you push.

Re-write history A similar approach to #2, you can forcefully remove commits. Since you tried two different ways to address the same bugs, you can now delete the unwanted attempts. If you have your master branch checked out, you can reset the branch to point to Commit C (Add Security). This will effectively remove Commits D and E from your history. Now you can merge (without conflicts) the newidea branch. Figure 6: Rewrite history Once completed, your history view should look something like Figure 6. Note: you should never re-write history once you’ve shared a repository.

Similar to #2, this will cause you, and any collaborators, a great deal of stress. Another problem with this approach is that you are hiding what you really did. If you ever wish to reexamine the original attempts to fix the UI and Core, you can’t. Revert and merge The best approach to this merge problem (IMHO), is to communicate to git exactly what you want to do. In this case you fixed a few problems, were not happy with your solution, so you fixed them a different way. In git speak, you committed D and E, you now want to revert D and E and merge commits F and G instead.

Unlike the rewriting history, this will actually create new commits to represent the reverted changes. The original attempts are recorded in the SCM along with the the fact that you reverted them. Figure 7: Reverting commits Reverting a commit is as easy as selecting it in the history view, and choosing Revert Commit from the context menu. You can now use the merge tool with ease. Once completed, your history view should look something like Figure 7.

Because you haven’t removed any commits, this approach is safe even if you’ve shared your repository. What do other think? Do you have different ideas for merging branches with conflicting changes? Remember, don’t fight your tools, just git ‘er done.

Eclipse Git Merge

@Alex, That’s why I said IMHO;). I think the real answer is ‘it depends’.

Best Eclipse Plugins

I was actually thinking of the case where the master branch was public (or a well accepted solution) and now somebody wanted to try out a different approach. In this case, having the history accurately reflect what you did could potentially be helpful down the road. If people are reviewing the history and ask “why didn’t you do this the most common way XYZ”, they will easily see, oh they did and reverted it, interesting Plus, once the branch is public, revert is still a safe operation (whereas history rewriting isn’t). I was going to mention rebase (in option number 3 — instead of using reset), but the interactive rebase needed to remove commits it not yet completed in egit. @christian Thank-you. Hum I created the diagram in google docs, but I shared them publicly (I thought).

Let me see what’s going on here. @alex#2 I think you’re right. Actually, I think the temporal interaction afforded by command line interfaces makes it easier to understand a sequence of commands — and this is exactly what git is. However, don’t underestimate the power of good tools. Eclipse Git (egit) is currently a mapping of the git commands to the Eclipse workbench, however, I envision that egit will start to evolve and begin to take advantage of the spacial aspects of the desktop (and other affordances of a graphical interfaces) to provide a more powerful working environment. We are already seeing this with the integration of Mylyn / gerrit / egit / wiki docs / etc We should also be mindful that new users will start be exposed to git through IDEs and may never interact with the command line. It’s important to educate them about how things work, but also provide them with solid tools to get their work done.