I don't follow. In either case two branches are combined into one:

With a merge commit anyone can see each original path, and the merge result (with its author), and even try the three-way merge again. With a rebase, the original context is lost (the original commits were replaced by the rebased versions).

A rebase is a lossy projection of the same operation. A rebase lies about its history, a merge does not.

▲

hinkley 4 days ago | parent [-]

Merge with conflicts can be resolved with changes in code that don’t belong to the person who resolved the merge, and are not attributed to the person who resolved the merge. Git blame shows someone else as the person who introduced the bug. When you do a rebase you’re only modifying your own commits, or those of someone sharing your branch.

	▲	anonymars 3 days ago \| parent [-]
		I'd really like to see an example of what you mean. Are you saying a git blame is attributing code to a person who did not write that code? Are cherry picks involved (which also screw up history)? https://devblogs.microsoft.com/oldnewthing/20180313-00/?p=98...