One thing I miss on every merge tool is full history context for both sides ("side" == ours/theirs).
i.e., I don't want to just see the final state of ours/theirs, but the changes that us/them did in order to get to those final states.
IOW, often, both sides of the diff are nearly identical, and I have to squint to see the actual difference, and make some additional effort to figure out the intent of each side.
A better format would be, for each side:
Original state -> change -> final state
- "Original state" would be normally identical for both sides
- "change" would be tiny and unique for each side, helps you see the intent of each side clearly
- "final state" is normally pretty similar between sides, (which is what troubles me, if no context given).
If you click on the files in the pull request, you can see the diff and the changes on the source and target branches at once. You can also search for diffs on both branches at once, to quickly see how they were introduced.
This is one reason I enjoy doing rebases more than merges - you apply one change at a time, and so get to see the history for at least one of the sides.
One thing that always hits me during rebasing is trying to figure out which side is which. Somehow it feels like sometimes they switch, though I'm sure that doesn't make sense.
I usually can keep it straight by thinking, which branch would Linus think is his? That’s ‘ours’, and the new, potentially code-breaking branch is ‘theirs’.
The sense is sort of reversed between rebase and merge. When rebasing, the branch you're rebasing onto is considered the canonical/local branch, despite not being the current branch when you issued "git rebase".
I definitely get lost in big rebases too, same experience. I look at two sides of a merge and even with 3-way turned on I still question which version is the one I want, obviously the point of conflict resolution is to keep the important bits of both sides but I still feel like it takes forever to do it
I've found myself wanting the same thing. Git's diff algorithms are sometimes not as smart as I wish they were. Recently, when merging master into my feature branch, I had an incoming one line change trigger a single diff that was nearly the size of an entire file. That change wasn't even in the same area of the file I had been working on. Being able to walk forward and backwards through the incoming changes would have resolved the issue much faster than comparing "ours" and "theirs" by eye to see what actually changed.
I like p4merge. It's the UI from perforce, but it's free and you can use it with Git easily. Most 3-way merge tools will show you: yours, theirs, base, and the final result.
I usually look at their commit logs for that file at that area, I also find it useful to commit the unresolved conflicts when doing a merge and then resolve them in later commits so I can look at what I did later if I need to fix a bad merge
vimdiff is another one. Searching for merge.tool and diff.tool in the git-config man page shows a list of programs that git supports for conflict resolution.
i.e., I don't want to just see the final state of ours/theirs, but the changes that us/them did in order to get to those final states.
IOW, often, both sides of the diff are nearly identical, and I have to squint to see the actual difference, and make some additional effort to figure out the intent of each side.
A better format would be, for each side:
Original state -> change -> final state
- "Original state" would be normally identical for both sides
- "change" would be tiny and unique for each side, helps you see the intent of each side clearly
- "final state" is normally pretty similar between sides, (which is what troubles me, if no context given).
Maybe I'm missing something, feel free to correct