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
Attachment:
signature.asc
Description: PGP signature
