  MINE | MERGED | THEIRS

where you can select elements from both and have them merge into the middle.

Or the p4 merge way of:

  MINE | THEIRS
  -------------
     MERGED

Even most GUI's for git do it this way actually.

Merging should not be a major issue, it should be a trivial annoyance.

It shouldn't drop you into an interactive rebase that invalidates every object after it (necessarily).

▲ ndriscoll a day ago | parent [-]

It doesn't "drop you into an interactive rebase" unless you tell it to. If you want to rebase, rebase. If you want to merge, merge. As you say, even most UIs for git show what you are saying you want.

▲

dijit a day ago | parent [-]

you’re right, when a merge conflict happens it drops you in “detached head” and writes a diff into your files which even when modified away require you to issue a special command to continue.

Its actually worse than interactive rebase.

“detached head” and “rebase” aren’t meaningful verbs to normal people… when all you want is to save a working version

	▲	ndriscoll a day ago \| parent [-]
		Merge conflicts don't put you into a detached head state. You stay on the branch where you ran git merge. Why would it change your checked out branch? The special command is just `git add` to stage your changes followed by `git commit` (or do it all in one command as `git commit - a`), same as any other changes. Rebase is something else. It's something you do on purpose because you specifically want to rewrite the history. Personally I use it a lot and expect everyone on my team to, but you can use git just fine without ever rebasing or even knowing it's there. Like I actually have no idea what you're talking about. Is your criticism actually targeted at some specific UI tool that's not git?