There is no merge argument that makes it do that.
There is a way to do that within a single merge, but this might be a bad idea. This kind of merge is called an evil merge, at least by some (see Evil merges in git? for various takes on what exactly an "evil merge" is). A way to do it that's "not evil" is to do the merge, commit the result, and then make a followup commit that puts things right. Another way to do it that's "not evil" is to make a commit that causes the merge to be correct, then do the merge. Either way you have two commits, one of which is the non-evil ordinary everyday merge.
But if you do want to do it as a single merge, devil-may-care as to whether it's evil or not, here is how you do that:
$ git checkout branch
$ git merge --no-commit -s ours master
... Git does the merge, but stops before committing ...
$ git rm -r -- subdir # needed only if there are files to remove
$ git checkout master -- subdir
$ git status # use git status often!
... you'll see some status ...
$ git diff --cached HEAD # optional: see what's changing vs tip of branch "branch"
... you'll see some status ...
$ git diff --cached --name-status HEAD # optional: see what files differ
... you'll see some status ...
$ git status # it's never wrong to use git status too often
... you'll see some status ...
... ok, we're really ready ...
$ git commit
<and write a good merge message>
Note that having made this merge, Git now believes that the correct result of combining the two commits you just combined, is whatever you just committed. This affects future merge operations!
Note the git rm -r step (I forgot this at first): you need this if there are files in the current (tip-of-branch) commit that aren't in the master tip commit, that should be removed in the merge. If there are no such files, git rm -r is not harmful, but does nothing useful: we're just going to replace all the files with the subsequent git checkout master -- subdir step.
