tell git to use ours merge strategy on specific files

$ git config merge.ours.driver true

or even

$ git config --global merge.ours.driver true

'ours' isn't one of the built-in merge drivers even though it's perfectly clear to you and me what it should do, and it seems git doesn't error out when a custom merge driver is undefined.

(true above is just the unix true command, its success says it made the local version look right, in this case by doing nothing to it.)

From my testing with git version 1.7.1 I find that unless there IS a requirement to merge, no merge driver will execute (regardless of what you put in the config, and regardless of any git attributes).

If you branch out from the "master" to your own local branch "bugfix" and then edit a bunch of stuff in your own branch, commit that. Afterwards you checkout the "master" branch again, then do something like:

git merge bugfix

You might expect the "merge=ours" attribute to protect you in this situation. It won't! Branch "bugfix" will stomp over branch "master" if there have been no edits to that particular file within the master branch since the time "bugfix" branched away from master. No edits implies no need to merge which implies don't run a merge driver. This seems such a common problem that git should have a particular attribute pre-defined to give a file absolute local protection from foreign merges, under ALL situations.

FWIW, I've read other people's opinions that config files should be local and private and not checked into git at all. I think that's kind of bollox: of course I do want to track changes in my config file. Of course the idea of a collaborative tool is that I want to be able to compare my config against what other people in my team are running, or compare the development config to the production config. The whole idea of a tool is that it helps you get your work done.

As a kludgy solution, the best I've come up with is a config directory with each config file having a different name (i.e. config/production config/test config/devel_joe config/devel_bill and so on) and all of these go into git. Then at deployment the actual working config file is copied out of that config directory. I think it's an ugly approach because it is a step backwards away from the idea of named branches, but at least it is safe.