a bunch of people have said that they feel embarrassed that they're still confused about which side of a merge conflict is which, even after many years using git.
I want to say that I have a hard time with it too (and I am uh EXTREMELY confident in my git skills at this point). Really appreciate everyone sharing their coping strategies for dealing with this not-very-clear UI.
@b0rk Wrote myself a script that had clear labelling about where changes were coming from and what branch was being updated, and wrapped that around git for my merges. 😁
(Mostly I use a single branch, push to head approach and do mob programming now, but! When I was doing more merges, that’s what I did.)
@thomasfuchs@b0rk
I just on Friday gave two of my classes a spiel to the effect of “it’s not you, it’s Git, it’s incredibly user-hostile and it’s not your fault.”
@b0rk I can’t make heads or tails from this after 15 years. Something just doesn’t click. diff3 helps sometimes to infer which is which based on a common middle, but IMHO this is all awful
@b0rk I'm not ashamed to admit it (though I probably should be) but I've literally resorted to cloning my branch in another directory to make sure my stuff makes it past the merge conflict if I'm not 100% sure.
@b0rk Without considering other aspects, it seems that one always wants to take the second (>>>) change as this represents local changes. Why, with the exception of maybe another (recent) commit on the remote on the exact same line(s) of code would one want to discard their changes?
@b0rk I proceed forward not really knowing which is which but it usually works out because I pretty much know what I want and I can figure out which pieces of each to stitch together to get there.
Not a great strategy. But maybe a useful data point.
@mjd@b0rk I find the "don't let it distract you" strategy particularly valuable in cases where you're rebasing commits that aren't all working towards the same goal, e.g. repeated false starts + reverts + retries.
I find I get much better results in that situation if I reduce myself to a "just apply both changes at once" automaton than if I clutter my mind with trying to understand what's actually going on, because what's actually going on is confusing, whereas the current subtask is simple!
@b0rk If I don’t already know where the changes in the diff came from and am sure I know which one is correct, I open both branches elsewhere and confirm which one I want.
@dachary@b0rk I remember that "HEAD" is almost always the stuff in my current working directory. But then there's the related "ours" and "theirs" which is ALWAYS confusing.
When dealing with non-trivial conflicts, I'll frequently use Kaleidoscope's graphical merge tool in 3-way mode. Then you see one file on the left, one on the right, and the center column is the resulting merged file. The 3 columns make it much easier to figure out the 2 starting contexts.
@b0rk I think the best clue from that diff is the commit message from one side. Sometimes I can tell by knowing what one of the branches is about.
But also, I mostly don't find I need to know which is which. In fact I resist trying to figure it out, on the basis that it's a distraction. I just make a snippet of code in which both changes have been applied, and move on. In diff3 mode that's usually easy, and I make fewer mistakes that way than if I think harder about the big picture!
@b0rk
I usually end up inspecting history with a GUI. (I like gitup.co for these sorts of task.)
This is a situation where GitHub fails extra hard, imo. It seems to me other version control systems somehow aren’t as confusing about how they show the conflict.
@b0rk If I don’t remember the context, I often use a helper (via git mergetool). I used to use DiffMerge but now use Kaleidoscope, but the UI in VSC isn’t bad, either.
Edit to add: all of those tools tend to be nicer about resolving simple conflicts quickly so I can focus on the ones which require more thought.
@b0rk I generally use the arrows on the assumption that "it's just like CVS or SVN, right?" but then second guess myself because I can never remember which commands reverse "mine" and "theirs" (is it just rebase?) and fall back to inspecting the code and trying to figure out what I meant.
@b0rk In a rebase conflict, I copy the SHA from the CLI conflict message (which frustratingly has a '...' glued to it which means you can't double-click to select it...), then in a separate terminal window do 'git show SHA' to try to understand what the commit wants to change. I generally don't ever do merge conflicts -- if there is one, I rebase the branch, resolve conflicts in that, then merge.
@b0rk There is a git config option to show a 3rd chunk, the common ancestor of both changes. But I'm not managing to find what it is on google, and looking in my .gitconfig files is not showing me anything useful!
@b0rk the first I guess, since left/first argument is "before" and right/second argument is "after" in diff/patch kind of contexts
(I've also occasionally done a diff the "wrong way" at times and been very confused for a bit before realising, so I guess it's kind of in my subconscious at this point?)
@b0rk IMHO it doesn’t really matter. Either you wrote the code and you should know the correct version, or you should look up the author and ask. Don’t merge something you don’t know about.
I have git mergetool set up to use p4, but I never know which side is which. I always work it out based on the bits it is asking me to resolve and what I can remember of what I did and what other people have done (or I've done elsewhere).
@b0rk I do whatever I can to get the conflict in “diff3” style instead (which might require some kind of --abort and repeating whatever I did)
I think this actually happened to me recently – I don’t remember why I didn’t get a diff3 diff, but I didn’t even try to understand it, I just reset and tried again with fixed config
Add comment