I personally am not a fan of unified history there, but I don't know how you'd avoid it in the "source-git"/"merged source" model.

For us it is not a problem. Upstream development happens on the upstream branches, if I want upstream history, I can check it there. If I want only downstream history, even though upstream is merged in, git is happy to give you logs of only what is exclusive to your branch:

'git log --no-merges foo..' where foo is the upstream tracked branch.

For packages I've worked on in RHEL world there have been two different approaches.

For RHEL QEMU we've kept a redhat/qemu-kvm.spec.template file in src-git, and its changelog gets updated at the same time as patches are merged into src-git. It gets synced across to dist-git automatically and Patches lines filled in when in dist-git. So packaging and code patches are intermixed in git commit history.

For RHEL libvirt the src-git already has a libvirt.spec.in file inherited from upstream. This spec is synced to dist-git manually when we rebased to a new version. Both %changelogs and Patch lines are only ever added in dist-git, when syncing. We don't generally modify the spec in src-git, though patches cherry-picked from upstream might modify the libvirt.spec.in, this would need to be manually changed in dist-git too later. git commit history is largely just code patches

Either way though I'm not bothered about changes to spec files obscuring the changes to sources. For packages which are patch heavy (which is where src-git is a big benefit), the spec file changes are relatively rare and don't hurt the signal/noise ratio in git history IME.