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.