Decide on github.com/sergi/go-diff dependency

[pjbgf]

go-git currently uses github.com/sergi/go-diff's v1.1.0 as a diff library. This version was released in Dec 22, 2019. All later versions of it contain a bug which blocks go-git from upgrading to them.

The bug has been opened for a few years now, and there is no indication as to when this will be fixed. In order to keep go-git dependencies in a healthy state, here are a few options we have, which I wanted to get some opinions on:

1) Fork the upstream version 1.1.0 into the go-git org, and maintain it based on go-git needs.

The additional maintainership burden on this must be taken into account if this was the way to go.

2) Copy only the required code into an internal package internal/diffmatchpatch/.

The upstream licenses (MIT and Apache 2.0) are largely aligned. This would remove the current issues, but may cause the two versions to grow apart even further.

3) Do nothing. Wait until the bug gets fixed, or until when a well-maintained alternative is found, by which point we migrate into it.

In the mean time, any CVE issues that may arise on indirect dependencies from that library will be dealt with via go.mod replace directive.

xref: #697 (comment)

[pjbgf]

cc @aymanbagabas @jfontan @hiddeco @mcuadros

[aymanbagabas]

There's also go-udiff which is an exported package of golang x/tools/internal/diff. There is an active proposal on making this package public in stdlib.

[pjbgf]

That would be great, let's hope that proposal goes forwards.

[hiddeco]

Proposal got declined. However, I think the notes in "alternatives" are sufficient to look at this as an alternative solution instead of waiting for the chance of the bug to get fixed and/or forking...

[AriehSchneier]

sergi/go-diff has merged a fix, I tested with this version and all our tests still pass:

github.com/sergi/go-diff v1.3.2-0.20230802210424-5b0b94c5c0d3

That said, I think it would still be prudent to try to replace it with a different library at some point as the support is extremely lacking.

[pjbgf]

Nice find @AriehSchneier. This could work as a short term solution, but I agree that in the long term it would be better to depend on a better maintained project.