Conversation

if you're dealing with a merge conflict in Git like this, how do you figure out which side the of the conflict comes from which branch? (you can pick more than one)

FRUITS = [
"apple",
<<<<<<< HEAD
"cherry",
=======
"banana",
>>>>>>> add-fruit
"orange",
]

0
0
0

@b0rk I guess...extended "look at the branch name" and run `git show` against the named things, giving each side of the tree and hopefully a little more context what is going on.

0
0
0

@b0rk it's just an awful situation. i keep thinking "does HEAD indicate the change i am attempting to apply, unnamed because it's as-yet uncommitted, or is it just the state of some tree whose name I don't care about"

2
0
0

@wingo i'm trying to think about what Git's official documentation should say about this situation other than "idk it sucks" haha

0
0
0
@wingo @b0rk I've found that by merge conflict time it's usually too late to really understand what's going on, it's just one of the pitfalls of the whole content tracker model git uses. I have better luck going back to the commits that touched the code, treating them as patches, and then logically re-applying them into the merge commit.
0
0
0

@b0rk My “other” is “get confused, probably get it wrong at least once, and abort/redo the rebase/merge”.

0
0
0

@b0rk For me, it's either a conflict that I can easily resolve and I don't have to think about where things come from, or I basically open another terminal window and I look at previous commits.

0
0
0

@suetanvil @benjamingeer @b0rk @wingo also, some form of three-way diff should be the default. it is so much easier to figure out what _should_ be there, with the additional context of "this is what it was like before either side of the merge started messing with it".

0
0
0