Resolve non-inline merge conflicts

[stefanhaller]

• PR Description

We offer an inline merge conflict editor for text conflicts (i.e. where both sides modify the same section of code). However, there are other types of conflicts that can't be resolved this way, for example when one side modifies a file and the other side deletes it. For these cases we would previously only show * Unmerged path in the main view, which isn't helpful. (Also, for some of these we would split the main view and show this text both in the unstaged changes and staged changes views, which is a bit embarrassing.) But more importantly, it was very unclear how to resolve such a conflict. The only option we had was to discard the file, which would basically pick "ours" and discard "theirs"; but there was no way to do the opposite.

This PR improves the situation in two ways:

• it shows elaborate help texts in the main view explaining the situation (which, in some obscure cases, can be extremely non-obvious, and a git status on the command line doesn't help at all either). For UD and DU conflicts we also show the diff of the side that didn't delete the file; this is usually essential for resolving the conflict properly, because it's likely that this diff needs to be applied manually somewhere else.
• when pressing enter, we show a dialog with options to keep the modified file or to delete it.

A note about terminology: a common way to describe the two sides of a merge is "ours" and "theirs". I dislike these terms, because while they work well for merges, they are backwards for rebases. I chose to avoid them in this PR, and to use the terms "current" and "incoming" instead (like in the conflict code lenses in VS Code), which I think work much better in general; however, they might not be easy to understand when they occur in the middle of a sentence, so maybe we should put them in quotes there.

• Please check if the PR fulfills these requirements

• Cheatsheets are up-to-date (run go generate ./...)
• Code has been formatted (see here)
• Tests have been added/updated (see here for the integration test guide)
• Text is internationalised (see here)
• If a new UserConfig entry was added, make sure it can be hot-reloaded (see here)
• Docs have been updated if necessary
• You've read through your own file changes for silly mistakes etc

[codacy-production]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
Report missing for a09ca591	✅ 97.35%

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (a09ca59)	Report Missing	Report Missing	Report Missing
Head commit (ebb576f)	54224	47007	86.69%

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#4431)	189	184	97.35%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings    Change summary preferences

Footnotes

1. Codacy didn't receive coverage data for the commit, or there was an error processing the received data. Check your integration for errors and validate that your coverage setup is correct. ↩

[jesseduffield]

however, they might not be easy to understand when they occur in the middle of a sentence, so maybe we should put them in quotes there.

I agree. Or, we could be more wording and say 'modified in the current changes and deleted in the incoming changes'

[jesseduffield]

couple things

[jesseduffield]

I would have put them both in the same order so that you can use muscle memory to make the choice. Given that this second one is 50/50, why not just retain the order of the first one? i.e. always have delete first.

[stefanhaller]

I found it more important not to have a destructive option as a default. And these AU/UA conflicts are so rare and probably so confusing that you won't be able to operate the dialog quickly and using muscle memory without looking. You'll have to read the choices carefully.

I'd prefer to keep the order this way, but I can also change it if you insist.

[jesseduffield]

Alright fair, let's keep it as-is

[stefanhaller]

I agree. Or, we could be more wording and say 'modified in the current changes and deleted in the incoming changes'

Ok, I went with that suggestion (47b93a3). I'm not super happy with the wording; I think "incoming changes" works very well, but "current changes" is not a term that I would intuitively use. But I guess it's ok, and I can't think of anything better.

[jesseduffield]

LGTM