Subject: Re: [PATCH v8 08/14] merge-resolve: rewrite in C

From: Junio C Hamano <[email-masked]>
Date: Wed, 17 Aug 2022 12:18:20 -0700

Elijah Newren <[email-masked]> writes:

> There's also another concern you tried to address in your other email;
> let me quote from that email here:
>
>> If you want to have an easy example of a custom merge strategy, then let's
>> have that easy example. `git-merge-resolve.sh` ain't that example.
>>
>> It would be a different matter if you had commented about
>> `git-merge-ours.sh`:
>> https://github.com/git/git/blob/v2.17.0/contrib/examples/git-merge-ours.sh
>> That _was_ a simple and easy example.
>
> ...and it was _utterly useless_ as an example.  It only checked that
> the user hadn't modified the index since HEAD.  It doesn't demonstrate
> anything about how to merge differing entries, since that merge
> strategy specifically ignores changes made on the other side.  Since
> merging differing entries is the whole point of writing a strategy, I
> see no educational value in that particular script.
>
> `git-merge-resolve.sh` may be an imperfect example, but it's certainly
> far superior to that.
> ...
> If someone makes a better example (which I agree could be done,
> especially if it added lots of comments about what was required and
> why), and ensures we keep useful test coverage (maybe using Junio's
> c-resolve suggestion in another email), then my concerns about
> reimplementing git-merge-resolve.sh in C go away.
>
> If that happens, then I still think it's a useless exercise to do the
> reimplementation -- unless someone can provide evidence of `-s
> resolve` being in use -- but it's not a harmful exercise and wouldn't
> concern me.
>
> If the better example and mechanism to retain good test coverage
> aren't provided, then I worry that reimplementing is a bunch of work
> for an at best theoretical benefit, coupled with a double whammy
> practical regression.

Ah, you said many things I wanted to say already.  Thanks.