Q:

Git merge strategy to ignore deleted files

I have special branch (release branch) which is an exact copy of master branch with some files and directories removed. No development is happening on this branch, however it must be in sync with master, so updates on master must be constantly pushed to that branch.
By doing a normal merge (git merge master) I constantly get conflicts like (a sample README file for example):
CONFLICT (delete/modify): README deleted in HEAD and modified in master
which is expected: I try to merge changes in files, that I've deleted. So, to resolve them I jut use git rm README.
To automate it, I though I could use automatic conflict resolution by specifying -X ours. Man pages suggest it is a right thing for me:
This option forces conflicting hunks to be auto-resolved cleanly by favoring our version. Changes from the other tree that do not conflict with our side are reflected to the
               merge result.
However, when I do git merge -s recursive -X ours master I still get the same unresolved delete/modify conflicts. What am I doing wrong? Is there another way to automate conflict resolution?

A:

There's probably a better way to do this, but I solved a similar problem by doing the merge (with the default merge strategy) and then running
git status | grep 'deleted by us' | awk '{print $4}' | xargs git rm

After this, you should resolve other conflicts as normal and then commit.
This just deletes all files that had been deleted on the current branch, which I think is what you want.

A:

git merge master
git status --porcelain | awk '{if ($1=="DU") print $2}' | xargs git rm
git commit

A:

By having a look at this question, it looks like the recursive strategy with ours or their option doesn't consider a deletion as a conflict.
What you can do though is use this feature to specify a specific strategy for some files. I would bet that the ours strategy (not option) would do the trick for those files.
EDIT:
As stated in the comment, you can't do this !
You should definitly contact Git mailing list if this is a very important feature to you (git@vger.kernel.org)

