top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

git rebase keeps giving the conflict

+3 votes
508 views

I cloned a new tree, made changes to file readme.txt meantime readme.txt in the remote has changed at the same location. When I do a git pull I got merge conflicts, I resolved the conflicts and did a 'git commit' now I did git rebase, somehow I'm seeing the conflict again, now I fixed the conflict and did 'git rebase --continue' the conflict shows up again.

How can I get around this, am I doing something wrong, or is there a bug in git ?

posted Sep 21, 2013 by Salil Agrawal

Looking for an answer?  Promote on:
Facebook Share Button Twitter Share Button LinkedIn Share Button

Similar Questions
+2 votes
GIT: Inexplicable merge conflict produced when when lines next to each other are changed

I posted this question to StackOverflow a while ago but no one answered it so I thought I'd try here.

Let's say I have a file with this content in master:

_____
Line 1
Line 2
Line 3
Line 4 
_____

Now say I create and checkout a new branch called Test. In this branch I change the file to this:

_____
Line 1
Line 2
Line 3 Modified
Line 4 
_____

and I commit this and switch back to master. In master I change the file to:

_____
Line 1
Line 2
Line 3
Line 4 Modified 
_____

and I commit. Now if I merge branch Test into master, I get a conflict.

Why can't git auto resolve this, as those are two entirely independent lines? If I tell git to edit conflicts using BeyondCompare as the difftool, BeyondCompare autoresolves this without even telling the user, since this isn't a real conflict (other merge tools we use at our company do so also). Is there a way to get git to autoresolve these?

I've tried the recursive and resolve merge strategies but neither do it.

It's an issue in our company because there are certain files where multiple developers change lines in close proximity and this causes many unnecessary conflicts when they pull.

+2 votes
Git merge commit message issue

In the past, when we do the merge in git, if conflicts occurred, when we commit, the conflict list will be appended to the default commit message automatically.

eg:
Conflicts:
....a.java
....b.java

Today, after using Git 2.3.0 for a merge, it seems now the conflict list was commented out by default.

I just searched a bit in the release notes, don't know whether below item has to do with this change.

"git interpret-trailers" learned to properly handle the "Conflicts:"
block at the end.

We quite rely on the default generated conflict list to reminder us about the "history".

Is this the default behavior now (conflict list commented out)?

+2 votes
Diff in git rebase -i commit message?

Could somebody tell me how to make git rebase -i show diff of squashed commits (for example), like git commit -v does it?

...