Re: Request for adding a simple mechanism to exclude files from Git merge operation

[Sergey Organov <sorganov@gmail.com>]

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> 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?

I believe we basically need support to apply different merge strategies
to different files.

I had similar problem a few times when I merged a long-standing branch
and, after I saw the result of merge, I was basically satisfied, except
I needed to revert a few sub-directories of the project (that gave huge
number of conflicts), to their original state, either of my current
branch, or of the branch being merged, depending on particular case. You
see, I knew exactly what I needed, yet I was not able to achieve my goal
without resorting to nasty kludges.

> Normally merges are symmetric, so if you want non-symmetric behavior,
> you have to define what it's supposed to be.

Yes, I'm ready to define what it's supposed to be. The problem is that
"git merge" won't let me, due to lack of support to apply different
merge strategies to different files.

As I see it, first step of improvements could be to support

  git merge -- <files>

where selected strategy applies only to <files>, and the rest of files
are kept intact (effectively applying "ours" strategy to them), along
with

  git merge --exclude=<files>

, to be able to exclude specific files (apply "ours" only to them)
rather than include.

[ As a side-note, please notice that after such changes, the "ours"
strategy could be deprecated (not that I think it should), as either:

   git merge <branch> --

or

   git merge --exclude=. <branch>

would do the trick. ]

The next step would then be to support

  git merge --force -- <files>

that would force to re-merge <files> with given strategy no matter what
their current status in the index is.

Even though such support would be enough for my specific use-case, it
doesn't provide suitable way to configure the default behavior. As a
more generic solution, a new syntax for "git merge" to specify what
merge strategy to apply to what files could be designed, and then
ability to put that syntax into a file for "git merge" to pick would
solve the problem of quasi-static configuration problem. Alternatively,
even more generic .gitignore way of doing things apparently could be
re-used to some degree by adding support for .gitmerge files.

-- Sergey