git merge strategy if you have a conflict

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:

git merge release-7.15.1 -m "merge release-7.15.1 to master"

...and ensure that the only conflict that arises is the 'release' file. When that happens, do a checkout:

git checkout --ours ./release

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.

Hey @RsrchBoy, thank you very much for your feedback. I was not aware of this problem, because until now i almost always used the theirs strategy.