Comments on: Git: You are in the middle of a conflicted merge. http://anarchogeek.com/2008/08/01/git-you-are-in-the-middle-of-a-conflicted-merge/ Wed, 02 May 2012 23:09:26 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: D. Spillman http://anarchogeek.com/2008/08/01/git-you-are-in-the-middle-of-a-conflicted-merge/comment-page-1/#comment-10377 D. Spillman Thu, 22 Mar 2012 04:59:14 +0000 http://anarchogeek.com/2008/08/01/git-you-are-in-the-middle-of-a-conflicted-merge#comment-10377 If you have to explain the message, then it is a bad message. A better message is a better solution (in this instance). Something like "Git was unable to automatically merge your changes with the master" would be better but this may still be unhelpful for some. A better solution is to suggest available options to fix the problem. For example: Your options are: 1. Discard your local changes. To do this use: git reset --hard then: git pull then retype your changes. 2. Manually merge you changes. To do this use: git mergetool then: git commit; git pull; git push If you have to explain the message, then it is a bad message. A better message is a better solution (in this instance).
Something like “Git was unable to automatically merge your changes with the master” would be better but this may still be unhelpful for some.
A better solution is to suggest available options to fix the problem.
For example:
Your options are:
1. Discard your local changes.
To do this use: git reset –hard
then: git pull
then retype your changes.
2. Manually merge you changes.
To do this use: git mergetool
then: git commit; git pull; git push

]]> By: Ha$H http://anarchogeek.com/2008/08/01/git-you-are-in-the-middle-of-a-conflicted-merge/comment-page-1/#comment-2069 Ha$H Tue, 15 Mar 2011 14:55:15 +0000 http://anarchogeek.com/2008/08/01/git-you-are-in-the-middle-of-a-conflicted-merge#comment-2069 Thank you, thank you, thank you so much :) Very useful article. Thank you, thank you, thank you so much :) Very useful article.

]]> By: Aaron Newton http://anarchogeek.com/2008/08/01/git-you-are-in-the-middle-of-a-conflicted-merge/comment-page-1/#comment-2054 Aaron Newton Wed, 13 Jan 2010 16:36:00 +0000 http://anarchogeek.com/2008/08/01/git-you-are-in-the-middle-of-a-conflicted-merge#comment-2054 If you have your diff editor configured you can just type "git mergetool" and it'll open the first conflicted file in that editor (you don't even have to paste in the path; it just does the first one). On OSX, it throws it to FileMerge, which 90% of the time is all I need. When you're done and save your file, close the editor (close it entirely, not just the window) and go back to your shell. The editor will have exited and the terminal should have moved on to the next file, hit enter and it launches again, repeat. When you're done continue with your steps above (add them, commit them). You'll likely have some .orig files to clean up, but that's usually not that tough. If you have your diff editor configured you can just type “git mergetool” and it’ll open the first conflicted file in that editor (you don’t even have to paste in the path; it just does the first one). On OSX, it throws it to FileMerge, which 90% of the time is all I need.

When you’re done and save your file, close the editor (close it entirely, not just the window) and go back to your shell. The editor will have exited and the terminal should have moved on to the next file, hit enter and it launches again, repeat.

When you’re done continue with your steps above (add them, commit them). You’ll likely have some .orig files to clean up, but that’s usually not that tough.

]]> By: William Brown http://anarchogeek.com/2008/08/01/git-you-are-in-the-middle-of-a-conflicted-merge/comment-page-1/#comment-2050 William Brown Sat, 02 Jan 2010 03:53:06 +0000 http://anarchogeek.com/2008/08/01/git-you-are-in-the-middle-of-a-conflicted-merge#comment-2050 I understand the frustration that it doesn't "just work", but what exactly do you expect it to do? You asked git to merge, it tried, but it couldn't figure out the correct merge automatically. So it gives you the same working directory file containing conflict markers that CVS or SVN do (I like to enable "merge.conflictsyle=diff3"), and, in addition, three original versions (both merge heads plus the common ancestor) in the index. Basically, the final fallback merge algorithm is "stop and ask the user what to do". And then it avoids doing any *more* damage until the unfinished merge situation is resolved somehow. Anyone who's accidentally checked a file *with* conflict markers into CVS will tell you how handy that safety feature is. You can always abandon the merge with "git reset --hard" and try again later. You can add cleverer and cleverer merge heuristics, but you can't find one that will *always* do the right thing, so you will always need a manual fallback. I mean, if branch A refactored function foo() one way and branch B did it a different way, there's no way for software to do that automatically. (In fact, Linus has specifically avoided such cleverness because it carries with it an unpleasant risk of quietly doing the *wrong* thing.) But I'm unclear on what better solution you expect. I understand the frustration that it doesn’t “just work”, but what exactly do you expect it to do? You asked git to merge, it tried, but it couldn’t figure out the correct merge automatically.

So it gives you the same working directory file containing conflict markers that CVS or SVN do (I like to enable “merge.conflictsyle=diff3″), and, in addition, three original versions (both merge heads plus the common ancestor) in the index.

Basically, the final fallback merge algorithm is “stop and ask the user what to do”.

And then it avoids doing any *more* damage until the unfinished merge situation is resolved somehow. Anyone who’s accidentally checked a file *with* conflict markers into CVS will tell you how handy that safety feature is.

You can always abandon the merge with “git reset –hard” and try again later.

You can add cleverer and cleverer merge heuristics, but you can’t find one that will *always* do the right thing, so you will always need a manual fallback. I mean, if branch A refactored function foo() one way and branch B did it a different way, there’s no way for software to do that automatically.

(In fact, Linus has specifically avoided such cleverness because it carries with it an unpleasant risk of quietly doing the *wrong* thing.)

But I’m unclear on what better solution you expect.

]]>