top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Sharing merge conflict resolution between multiple developers on GIT?

0 votes
412 views

At $dayjob we maintain internal forks of the a number of upstream repositories.

Unsurprisingly updating these forks can be extremely problematic, especially when it's only one person doing the merge. Fortunately most of us are in the same physical location so it is possible to drag in someone who knows more about the code than the person merging but I can't see that scaling with remote developers.

Is there any way where we could share the conflict resolution around but still end up with a single merge commit. I'm thinking of something like the following workflow

developer A:
git merge $upstream

git mergetool ...

git commit -m "WIP: Merge upstream" --something-like--all-but-not

developer B:
git pull developer_A
git reset HEAD^

git push

Any thoughts on if something like this is currently possible? Is this something other git users would find useful?

posted Aug 11, 2014 by Tarun Singhal

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

0 votes

One idea that immediately comes to me is to use something like "rerere" (not its implementation and storage, but the underlying idea) enhanced with the trick I use to fix-up merges in my daily integration cycle (look for "merge-fix" in howto/maintain-git.txt in Documentation/).

developer A:
git merge $upstream

And then commit this immediately, together with conflict markers (i.e. "commit -a"), and discard it with "reset --hard HEAD^" *after* storing it somewhere safe. And then redo the same merge, resolve the conflicts and commit the usual way.

The difference between the final conflict resolution and the original conflicted state can be used as a reference for others to redo the same conflict resolution later elsewhere. That can most easily be done by creating a commit that records the final state whose parent is the one you recorded the initial conflicted state.

So, the "recording" phase may go something like this:

 git checkout $this
 git merge $that
 git commit -a -m 'merge-fix/$this-$that preimage'
 git branch merge-fix/$this-$that
 git reset --hard HEAD^
 git merge $that
 edit
 git commit -a -m 'merge $that to $this'
 git checkout merge-fix/$this-$that
 git read-tree -m -u HEAD $this
 git commit -a -m 'merge-fix/$this-$that postimage'

The rough idea is "git show merge-fix/$this-$that" will show the "patch" you can apply on top of the conflicted state other people would get by running "git merge $that" while on "$this" branch.

"rerere" essentially does the above recording (and replaying) per-path and it comes with a clever indexing scheme to identify which previous conflict resolution would apply to the conflicts you see in your working tree.

answer Aug 11, 2014 by Honey
Similar Questions
+2 votes

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.

0 votes

I work on some files and push/merge them to the remote server. Sometimes I get merge conflicts on those files and have to fix them. That's completely fine. I get that.

What I don't understand is that sometimes during this process I will get merge conflicts in files _I have never touched_. In fact they are in a completely different series of directories to the one I am working on and someone else project entirely. How am I meant to know how to fix these? I dont know what the other developer wanted to do and if they have done it right.

I thought git only merged/pushed the files you have changed? If someone else has changed Group A files on the remote repo, why must I change my local Group A files when I am _pushing _completely different set of Group B files?

Sure, Id understand if I were pulling files down to my local and had to resolve merge conflicts then, but this isn't happening when I push the files up.

Any help or advice is much appreciated. Sorry if I sound frustrated - I am really trying hard to get my head round this whole git thing but its just so weird.

+2 votes

Let's say I have two identical branches: master and topic. In master I remove some code, i.e. function bar(). In topic I do the same (commit) and after some time I realize I need bar() and revert previous commit
with removal.

So I end with master with no bar() and topic with bar() in its original state. When I merge I get code without bar() and no merge conflict (recursive or resolve strategies). Is it possible to detect such situations as conflicts? When bar() is C++ virtual there is no possibility to catch this with compiler.

+3 votes

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 ?

...