git merge strategy for static config file in each branch

Question

We need a systematic way of ignoring a specific config file for the branches we maintain on git.

i.e. we have a config.xml file with database, environment, and other info across 'develop' and 'master' branches that we'd like to keep out of the outcomes of 'git merge'.

We followed the SCM book instructions for merge strategies, but git still seem to be merging config.xml when we do branch merges:
http://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes#Merge-Strategies

I've also had a look at this SO post which require conscious programmer effort to selectively ignore the config.xml file - seem to be prune to error:
Different configs in each git branch

There's also this SO post which explains the different git merge strategies, other than ours, none of the others seem to suit our purpose:
When would you use the different git merge strategies?

I'm curious what methods you guys use to control the changes to config files that stays pretty consistent in each branch without having 'git merge' mess things up?

Answer 1

The issue with a merge driver (like an "ours" strategy) is, as I mentioned in ".gitattributes & individual merge strategy for a file":

The merge driver is only called in non-trivial cases, i.e. if both master and test have touched setup (and you need to define the merge driver ours first).

I used such a strategy in "How do I tell git to always select my local version for conflicted merges on a specific file?", but it did involved a modification in both branches.

For some files with different settings, another option would be a content filter driver, as in "Keep settings in branch"

^{(image shown in "Customizing Git - Git Attributes", from "Pro Git book")}

That allows you to keep in version control:

• template file for the settings file itself, with placeholder sections in it (like @@PORT@@)
• a script able to take a template file and replace the value placeholders with the right value depending on the branch checked out or the content.
• multiple value files in order to version the right values for different context.
  Since those files are named differently and only modified in their respective branch, they are not involved in a merge.