git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Tiran Meltser <Tiran.Meltser@mavenir.com>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>,
	Amir Yosef <Amir.Yosef@mavenir.com>
Subject: Re: Request for adding a simple mechanism to exclude files from Git merge operation
Date: Mon, 22 Jun 2020 19:41:22 +0000	[thread overview]
Message-ID: <20200622194122.GN6531@camp.crustytoothpaste.net> (raw)
In-Reply-To: <DM6PR11MB27958B80E3994CEEF13971ECE5990@DM6PR11MB2795.namprd11.prod.outlook.com>

[-- Attachment #1: Type: text/plain, Size: 1644 bytes --]

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

  parent reply	other threads:[~2020-06-22 19:41 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-20 18:21 Request for adding a simple mechanism to exclude files from Git merge operation Tiran Meltser
2020-06-21 15:43 ` Philip Oakley
2020-06-22 18:42   ` [E] " Tiran Meltser
2020-06-22 19:41 ` brian m. carlson [this message]
2020-06-23 12:44   ` Sergey Organov
2020-06-23 16:16     ` Philip Oakley
2020-06-23 17:23       ` Sergey Organov
2020-06-23 17:08     ` Elijah Newren
2020-06-23 20:19       ` Sergey Organov
2020-06-23 21:46         ` Elijah Newren
2020-06-23 22:57           ` Chris Torek
2020-06-24 19:15           ` Sergey Organov
2020-06-23 22:38       ` Junio C Hamano
2020-06-24 18:03         ` Sergey Organov
2020-06-24 22:38           ` Junio C Hamano
2020-06-25 11:46             ` Sergey Organov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200622194122.GN6531@camp.crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=Amir.Yosef@mavenir.com \
    --cc=Tiran.Meltser@mavenir.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).