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).

Maybe I'm missing something, feel free to correct

> 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.

I'm curious, would something like this help you better understand a complex merge?

https://public.gitsense.com/insight/github?r=Microsoft/vscod...

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.

Disclaimer: I'm the creator behind GitSense

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

Me too, but it's still possible to encounter conflicts during rebases. This tool might help with those.

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.

This happens to me regularly with our .csproj files. I'm convinced it has something to do with our line endings...

What triggered the diff? Always trying to learn more Git nonsense.

Did they re-indent, change line endings, or strip end of line whitespace?

Aren't you just describing doing a proper 3-way merge?

Could be, thanks for the pointer.

But the 3-way merge apps I remember conflate the past context with the would-be result, which was confusing.

Googling now I see that one of them has distinct "Reference view" and "Edit view" tabs - sounds like what I was looking for.

Any recommended 3-way app?

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.

https://www.perforce.com/downloads/visual-merge-tool

Example:

https://www.perforce.com/sites/default/files/image/2017-06/s...

Meld is another popular Linux one, but I've somehow always been more confused than helped by the 3-way diff.

The one built into jetbrains ides is great too.

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

Check out kdiff3

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.

Any non-trivial merge conflict requires producing a hybrid of the two versions. From the screenshot it looks like all you can do is select one of the two versions. Isn't that extremely limiting?

Also it looks like this doesn't show the ancestor version, which is a shame as that's extremely useful.

What I frequently have trouble with is knowing what is represented by “theirs” and “ours”. I wish it would just tell me the branch name instead because sometimes both commits are logically “ours” or “theirs”.

Obviously that would only work for ‘git merge branch’ scenarios and the like but it’d be great.

If I hate one thing, its merges denoted by <<<< old blah >>>> new bleaugh <<<<

of all the diff notations, for some reason FreeBSD updater and git merge chose the worst (for me at least)

An IMHO significant improvement is setting merge.conflictStyle = diff3, so you get to see the original code as well:

  <<<<<<<
  My new code
  |||||||
  The original code
  =======
  The conflicting 'theirs' code
  >>>>>>>

Same option for the non-git regular 'patch' command is "--merge=diff3".

What is your favorite notation for merge boundaries?

See above: the one which provides the most context.

For anyone using JetBrains tools like IntelliJ or similar, note that they all include a nice diff/merge tool: https://www.jetbrains.com/help/idea/running-intellij-idea-as...

If you can't install with brew: https://github.com/mkchoi212/fac/issues/9

It works now! `brew tap mkchoi212/fac https://github.com/mkchoi212/fac.git && brew install fac`

What's the difference between a TUI and a CUI?

Curses User Interface?

There isn't one.

I like the merge tool i Gitkraken, it makes it easy to choose one side for each conflict or edit the result directly.

https://support.gitkraken.com/working-with-repositories/bran...

Haven't tested this yet but for now my preferred solution is to edit the conflict markers directly in vs code then stage.

I have basically the same complaint about most of the mergetools I've used; they tend to just do more than I want. I'm sure that's largely a PEBKAC problem, but..... ¯\_(ツ)_/¯

Definitely going to take a look at this; you screenshots look promising.

Have you looked at https://github.com/Peaker/git-mediate ?

Everyone I talked into using it had always initially thought "meh" but later thanked me - claiming it's a huge life-saver :)

It makes solving conflicts into a fun mechanical game while reducing erroneous merges by a lot.

Yeah most CLI mergetools are awefull.. if you want a nice git GUI, just use SmartGit. https://www.syntevo.com/smartgit

Or Visual Studio Code.

I use mostly https://github.com/mhagger/git-imerge for complex merges. imerge + meld is wonderful...

Looks nice! Would be great if it could show a 3-way diff with the common parent.

I had a merge to do today so I installed and tried it. I liked it! Great context for each side of the change and great keyboard controls.

Thanks for creating this mkchoi212!

The diff/merge tools shipped with Perforce are good.

They can be used with git as well.

I find "beyond compare" to be a very good merge tool. It's not free, but not very expensive either, and works well with git.

(I'm not affiliated with them in any way)

Beyond Compare is a good tool. It allows to compare full directories, ignore whitespace, etc.

I recommend Perforce's as a merge tool because it is better than average at the specific task of merging.

Perforce's P4Merge is the least-worst (free) merge app I've found for Mac. I use it for git and hg. That said, I'm always open for recommendations for something better.

btw, you can download P4Merge (aka "Helix Visual Merge Tool") here:

https://www.perforce.com/downloads/visual-merge-tool

https://semanticmerge.com seemed unique to me, and https://www.gmaster.io experiments with going farther.

Semantic patching can be good to resolve conflicts, but version control operates with non-semantic changes.

This can be frustrating at times, since many code bases cannot be reformatted or refactored because it affects version control history.

Yep, hated perforce, but the merger is quite good. In fact so good that for a time I used it standalone on git and svn projects too.

Nowdays I'm using webstorm and it's differ/merger is very very good, but ymmv.

IntelliJ (and specialized versions like Webstorm) has a very good diff tool, integration with version control, etc.

An underused feature is "local history", which is a local cache of all local changes. This can be a lifesaver sometimes.

First, what is CUI??

Following links on github, apparently it's Console User Interface. Looking at the project, it's what I've always known as a TUI (Text User Interface). I wonder why this new acronym appeared. It's even causing confusion with Commandline User Interface which sounds like CLI (Command Line Interface) which should be a different type of interface from TUI.

Character User Interface or Console User Interface (https://en.wikipedia.org/wiki/Command-line_interface)

Commandline User Interface

wow!

What's https://avatars0.githubusercontent.com/u/5487597 supposed to be, funny?

Likely to have been conceived by George Clinton himself, whose taste is clearly impenetrable by us less funky souls: https://goo.gl/YZJDi5