It seems other have tried and failed to force a conflict when Git decides there is none.
This SO question "Git merge - manual merge - forcing conflic having WHOLE old and new file version" concludes in the comments:
What I am most afraid is that answer: "it's not possible, cause it's the way git works".
And "Need GIT workflow suggestion" mentions trying:
*.xml merge=Unset into my .gitattributes file.
  Or a custom merge driver into ~/.gitconfig trying to cause the auto-merge to fail
In other words, that might not be the right approach.
If you are certain that all the modifications introduced by your merge shouldn't be here, then you can try:
git clone yourRepo aCloneRepo
cd aCloneRepo
git merge --no-commit --no-ff origin/source_branch
# simply overwrite any change file by the ones in ..\yourRepo
git add .
git commit -m "merge"
Note that the final "git merge" will work even though your git status mentions there is nothing to commit (since you restore the content of all modified files).
It will record the merge in a new commit.
That will give you:
C:\Users\VonC\prog\git\tests\mergekeep\r4>git lg
*   a6a1588 - (HEAD, master) merge (2 minutes ago) <VonC>
|\
| * 1bcd75d - (origin/b) addition (2 hours ago) <VonC>
|/
* 9d2e8fb - (origin/master, origin/HEAD) first file (2 hours ago) <VonC>
But with local files unchanged.
And if you try again to merge your branch, you will get:
C:\Users\VonC\prog\git\tests\mergekeep\r4>git merge origin/b
Already up-to-date.
However, that workaround is cumbersome, involves a clone and some manual copy or rsynch from one working tree to another.
I tried to play with various git reset commands or plumbing commands like git update-index, but without much success.