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/ Sat, 11 Feb 2012 01:13:10 +0000 hourly 1 http://wordpress.org/?v=3.3.1 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.

]]>