1

I am trying to jump over my shadow and finally learn git at a basic level. Like countless beginners before me I ran into the dreaded "egit rejected non-fast-forward" error when trying to push after merging in the remote changes and "marking as merged".

It seems like I already found a solution for this problem, but it is cumbersome and not compatible with the eclipse compare editor. I do it like this:

  1. Push my changes - causes the "egit rejected non-fast-forward" error
  2. Pull changes - The compare editor now contains <, = and > markers. I can't comfortably compare and push around changes as the right side of the compare editor is empty and the left contains my changes and the remote conflicting changes above each other, which is pretty useless.
  3. Painfully pick the parts I want by manually editing the text.

Am I using egit the right way?
Is there a way to properly use both sides of the compare editor?

I want to see my version which will be pushed and it's differences to the current remote version at all times during the merge.

ASA
  • 1,911
  • 3
  • 20
  • 37

1 Answers1

1

I'm not familiar with egit, but it sounds like you are dealing with a merge conflict. Am I right in assuming that someone else also has push access to the branch you're working on? What likely happened is they pushed new changes to the branch, which is what is causing the rejection. And by pulling, you're trying to merge in some conflicting changes that you have to resolve. Here is a better explanation of the same problem.

The bad news is that merge conflicts always have to be resolved manually. The good news is that it looks like egit provides a merge tool for resolving these conflicts. This egit wiki page might help you find the comparison tool that you're looking for. Basically, just select the file that has conflicts and then select Team > Merge Tool .


If that doesn't work, you can always confidently resolve merge conflicts just by using the git merge markers (<, >, and =). Read this for a detailed explanation of how those are used in Git. Basically, anything below <<< and above === will be your changes. The code below === and above >>> will be their changes. And you either have to pick which side you want, or you can customize it even further. by deleting everything and re-writing the code yourself.

Here's an example. This is something you might see when resolving a merge conflict. The top show you the commit at your local HEAD, your version of the commit. And the bottom, below the === shows the commit at origin/master, the version you just pulled in.

<<<<<< HEAD:test.html
<h1>This is my version</h1>
======
This is their version
>>>>>> origin/master:test.html

To keep only your version, you could just replace that entire block with this. It's like the arrows and equal signs are giving you a choice. Do you want the top (yours), or the bottom (theirs)?

<h1>This is my version</h1>

Alternatively, maybe you want a combination of both. Here, you would be keeping your <h1> html tag, but using their text.

<h1>This is their version</h1>

I hope this helps you feel more comfortable with resolving merge conflicts. If you want to learn more about Git, I always recommend git-scm.

Community
  • 1
  • 1
Tim Park
  • 2,446
  • 2
  • 11
  • 13