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

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