The behavior you describe should not occur. Adding the files to the branch and re-merging is a correct procedure.
Git doesn't know or care that you're "re-introducing" code; to git files are added, and that itself is a change. So the fact that files with the same name and content were earlier deleted, or that they hadn't been otherwise modified on the branch, or anything else... doesn't matter. You're introducing a whole bunch of concepts that don't really exist, and complicating your view of what git does.
You had
O --- x --- x --- x <--(master)
\
A --- B --- C --- D <--(branch)
and maybe A deleted foo/*. You merged
O --- x -- x --- x -- M <--(master)
\ /
A --- B --- C --- D <--(branch)
and now the deletion of foo/* was carried into M. To fix this you add a commit to branch
O --- x -- x --- x -- M <--(master)
\ /
A --- B --- C --- D --- E <--(branch)
and E creates files at foo/*. If you merge this to master:
O --- x -- x --- x -- M --- M2 <--(master)
\ / /
A --- B --- C --- D --- E <--(branch)
the merge base is D. Only D, E, and M are examined to produce M2. Because M doesn't do anything at foo/*, while E creates files at foo/*, M2 will get the files. The history before D doesn't matter.
This is documented behavior which has worked in numerous tests for countless users, so I would advise that you re-check your work and make sure you re-added and merged in the way you describe.