Have a look at go-difflib

[zimmski]

Have a look at https://github.com/pmezard/go-difflib and add everything that is implemented in go-difflib but missing in go-diff as an issue.

[h8liu]

some drive-by notes:

difflib is ported from python difflib, and it is a basic line diff. where diffmatchpatch seems to have no explicit line diff output. I don't think diffmatchpatch even split the strings into lines first.

fwiw, I did some cleanup on both libs on my own (see https://github.com/shanhuio/third).

just curious, how did you get the ownership of this repo?

[zimmski]

That is right, go-diff does not split the processed strings. I did not yet have a chance to look at the algorithms of go-difflib (e.g. SequenceMatcher). Is it worth to take a look?
I guess that means that at least #57, #58 and #69 have to be fully implemented, or did I miss something?

I saw your fork when I went through every fork of go-diff #38. I did not include any changes of yours because the commit messages are empty. Would you be interested in doing a PR?

I do not have ownership of this repository, I have collaborator rights. I simply applied for it, otherwise I would have been forced to maintain a fork of this repository. Why are you asking?

[h8liu]

It has some interesting stuff on marking junks, besides that, it is a relatively standard one. dmp is more complicated.

for unified and context format, difflib implements the marshalling to the output, but not the unmarshaling from an input. it does not have a patcher.

not really interested on a pull request. many of my changes (like function renaming) will break other downstream packages.

this repo was dormant for a long time. I am just curious if there is any background story that leads you here. :)

[zimmski]

Then I will simply close this issue since everything that should be implemented has an open issue.

We (@work) are doing a lot of diffs (mostly for source code) and I do not want to call external tools all the time. The reason why I am maintaining this now is that it is annoying when you hit bugs and you see that they are fixed upstream but the original author has moved to other projects. IMHO every company should contribute to at least one OSS project they are using. For us it is not just one, but that is OK 👍