Joined August 2011
·
Achievements
121 Karma
0 Total ProTip Views

T-Rex 3
Have at least three original repos where C is the dominant language

Raven
Have at least one original repo where some form of shell script is the dominant language

Python
Would you expect anything less? Have at least one original repo where Python is the dominant language

T-Rex
Have at least one original repo where C is the dominant language

Epidexipteryx
Have at least one original repo where C++ is the dominant language

Philanthropist
Truly improve developer quality of life by sharing at least 50 individual open source projects

Velociraptor
Have at least one original repo where Perl is the dominant language

Velociraptor 3
Have at least three original repos where Perl is the dominant language

Walrus
The walrus is no stranger to variety. Use at least 4 different languages throughout all your repos

Altruist
Increase developer well-being by sharing at least 20 open source projects

Forked
Have a project valued enough to be forked by someone else

Charity
Fork and commit to someone's open source project in need
From experience, this is a very dangerous thing to do -- using the 'ours' merge strategy should be reserved for extraordinary situations.
Imagine you have a hotfix that has been merged into production... but has not been merged back into your development branch (lets call it master) yet. If you merged with the command above, git log would show that the hotfix commit had been merged into master, but the actual change would be silently discarded. (That is, the history is joined, but the content is lost.)
Much safer would be to handle the conflict in the regular way:
...and ensure that the only conflict that arises is the 'release' file. When that happens, do a checkout:
At this point, the release file in the working directory will be the same as the file recorded in the tip of master (that is, HEAD). You can now add the file to the index and commit -- assuming that no other conflicts arise.
This way, you achieve what you want -- the release file staying the way it was in master w/o having to repeatedly dig into it to resolve things-- without playing Time Lord too much with history. That's the problem with 'ours' as a merge strategy: it messes with people's expectations of how a branch's history works in unexpected and surprising ways.