On 2020-06-20 at 18:21:40, Tiran Meltser wrote:
> Hi,
> This topic is quite common in various use cases (e.g. production configuration vs. staging one) and there are quite a few talks about it in the web.
> Nevertheless, there is no specific solution to this problem, only partial workarounds (including the famous merge driver “ours”).

In general, this is a hard problem.  When you perform a merge, you're
asking to incorporate changes from both heads against a common merge
base.  What does it mean when you want to merge two branches together
but not make any changes?  Which version do you want, ours or theirs?
Normally merges are symmetric, so if you want non-symmetric behavior,
you have to define what it's supposed to be.

In addition, it's probably not the case that you want _never_ to modify
the contents of a file on a merge.  For example, if you have a feature
branch to update the production configuration to fix an issue or add a
new option, you probably do very much want that merge to succeed and not
be a no-op, so a configuration in .gitattributes may not be helpful for
your use case.

Because this is such a tricky problem and there usually isn't a
consistent set of behavior that people _always_ want to apply (unlike,
say, line endings), the general recommendation here is that folks just
avoid this problem altogether.  For example, your repository can contain
configs for development, production, and staging and a script can copy
the appropriate one into place based on an environment variable or
hostname.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204