Elijah Newren <newren@xxxxxxxxx> 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.
