Re: Feature request: a merge strategy that makes any file difference a merge conflict
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Mar 29, 2024, 19:40 UTC
- Message-ID
- <xmqqfrw8ygg2.fsf@gitster.g>
- In-Reply-To
- <CAAJCdQQB3_DWOTCTbb-TAkLUX_XVd5TBd3z0M2_KrHxKxr69Kw@mail.gmail.com>
Michael Ernst <mernst@cs.washington.edu> writes:
Show 5 quoted lines
> Git's built-in merge strategies, such as ort, sometimes create a > clean-but-incorrect merge. A merge driver or a mergetool cannot be > used to correct such problems, because a merge driver or mergetool is > only called when the strategy resulted in a conflict (so far as I > understand).
A custom low-level merge driver is always called when selected via the attribute mechansism (see how merge-ll.c:ll_merge() calls find_ll_merge_driver()) and participates in a content-level 3-way merge.
If you are trying to interfere with cases that a content-level 3-way merge does not kick in (e.g., your side did not change anything in the file since their history forked, and they modified the file; the tree level 3-way merge will resolve it to take their version), then it is true that the low-level merge driver is not invoked, but I somehow get an impression from the above description that it is not what you are trying to do.
> It is challenging to write a merge strategy, but it is > much easier to write a merge driver or a mergetool.
A merge strategy is about performing three-way merge at the tree level, figuring out which three variants of contents to hand to a merge driver that handles the content-level three-way merge. They serve totally different purposes and comparing them is like comparing apples and oranges.