It would be nice if you checked out lazygit and consider adding support to it's recently added OSC1717, adding supporting for staging in the main diff view directly: https://github.com/stefanhaller/diff-line-metadata-spec
Also it would be nice to have a more thorough and comprehensive comparison against difftastic, because I don't think there are much, or even any difference to code diffing compared to it: https://ivankovic.github.io/omnidiff/showcase/
Does yours support move + change detection across different files, like A/before.rs => B/after.rs (~some changes)?
An extremely thorough comparison against difftastic is in the research/ directory. I don't recommend reading it, unless you are really into diffs. Even describing the dataset takes a good half an hour.
> Difftastic is perfect on 64% of diffs and near-perfect on 17% more.
> Omnidiff is perfect on 90% of diffs and near-perfect on 5% more.
I did not find examples in the repo or any way to test what "perfect" or "near perfect" in those cases mean. On the playground you compare against unix diff only. Based on my quick comparisons with difft, I do not see much difference. Could you add a link to comparisons or show how it differs and what are those numbers based on??? I'm not dismissive, just looking for a proof or showcase.
For me the biggest issue is “git rebase” merge conflicts because the surrounding context was modified (especially near beginning/end of functions where the context includes unrelated stuff), or similar in a markdown document.
(If commit A adds a line to the end of a bullet list in markdown and commit B does the same, they will conflict even though resolution is trivial for a human)
the resolution depends on a deeper understanding of the contents of the list and whether they are ordered according to some scheme (in which case you will need to look at the two lines and see which one goes first)
Nicely done OP. Does it do 3-way diffs for merges as well? The instructions only mention the two-way `git difftool` configuration so maybe that'll be a future feature?
Any interest in getting the setup upstreamed[1] so that users only need to `git config --global diff.tool omnidiff` to enable it by default? Disclosure: I created `git difftool` a long time ago, and am always happy when builtin support for useful tools are added to it. Feel free to reach out if you'd like help making that happen.
At the moment the algorithm for code diffing is a particularly efficient implementation of APTED which is a tree diffing algorithm that doesn’t natively construct anything useful for a three way diff. I have a notebook with a bunch of failed attempts at a good algorithm for a three way merge, but so far nothing particularly impressive.
It’s a long term goal to solve, but it’s the hardest one.
I’ll definitely reach out to you to upstream. Thank you for the kind offer!
How do you handle degenerate trees? I’m curious what heuristics are used in practice to eg backtrack or whatever. I’m not very well versed in TED but superficially the problem seems to resemble wave function collapse.
In practice, tree hashing is doing a huge amount of work because most diffs are tiny. Half of all diffs are less than 10 lines, so a hash can extremely quickly match large subtrees.
In a profoundly degenerate case of a C++ header file with only a 20MB array of bytes, it detects a degenerate tree and uses Myers O(N) sequence diffing algorithm instead of treating it as a tree.
How would one craft an input that maximizes the runtime of your diff while staying below some (reasonable) bound of edit distance apart? Basically suppose I wanted to provide a malicious diff designed to hang or timeout the diff program, how would I construct it?
You need to maximize the size of the residual tree sent to the final APTED step.
I actually don’t know how to do that and stay under a bounded edit distance.
Alternatively, you can crash it if you just encode the entire “Star Trek - In the pale moonlight” episode as a sequence of bytes in a const int array in C++.
I’m not sure if I’m understanding this correctly : so for the remaining 0.05% of code changes, this tool would just… miss it? That seems horrible for a diff tool :O
It's a tradeoff. The length itself is not a problem. It will happily diff normal multi-MB files.
The problem is the degenerative syntax tree that TreeSitter produces in case of, for example a multi-million array of bytes. This causes a stack overflow in the TreeSitter C code which takes down the Rust process with it.
The correct solution would be to prevent TS from crashing, or isolate the C<->Rust boundary better.
Or just, not support that for v0.3. Because if you are diffing the collected works of Shakespeare as a binary blob in a C++ header, maybe diffing isn't your biggest problem.
The crash will happen in TreeSitter which is a widely used AST library that all modern editors, including neovim, depend on for syntax highlighting and which is also used by many LSPs.
Delta has a really nice way to show diffs with its diff-so-fancy mode, it's more similar to GitHub's UI where not only the line is colored up differently but there's a different shade of color to highlight the characters.
In OmniDiff's readme and web version I didn't see a way to do that.
In a different comment you mentioned OmniDiff is much better than Delta and you mentioned "About a third of diffs are significantly better.". Can you provide some examples of these? I've never seen Delta fail a diff.
Also Delta has a package for Arch in its official repos. For folks who just want a "it works" experience, that's a pretty big win. With Delta the same package can be installed in the same way on Debian, Arch and macOS with Brew using standard package managers. With OmniDiff, there's 3 different ways to install it (manual deb package on Debian, manual package compile on Arch and brew install on a Mac). Just something to think about, as someone who has public dotfiles that work in those 3 environments, I'd skip OmniDiff based on this alone.
OmniDiff is character based by default. It will only highlight the changed characters. I suppose I could add an option to additionally highlight the line as well. Thanks for the feedback!
As for packaging. Unfortunately AUR is closed at the moment due to spam. I can add brew commands for Linux, happily.
In terms of “better”. It’s actually somewhat complex, but a simple way to think about it is that if you move a function up or down in the same class, text-based diffs paint that as “Deleted here, Inserted there” where ideally you would want it to say “Moved”.
OmniDiff also works directly with git diff and git log -p, through GIT_EXTERNAL_DIFF. This path needs no difftool config:
GIT_EXTERNAL_DIFF=omnidiff git diff
Piping the output of `git diff` might withhold information from the tool that it needs for its feature set, while `delta` is just a different way to display any diff output.
cool to see fresh Rust software with copyleft license !
I feel safer, as a user, enjoying the freedoms that the AGPL provides me. (No evil middleman will be able to give me non-free versions of this program.)
As long as they open source all modifications and follow AGPL to the letter so that anyone can self-host the version they are selling, I’m ok with that.
AGPL totally allows commercial use. You just have to give back.
You have a good core idea here. You're pretty much killing your project in infancy with the AGPL+donation license model. Meanwhile, some other projects will take the core idea of "language aware differ" and release BSD, and one of those will win, including perhaps making it into git/future version controls.
IMO, you should seek to make this a standard that wins, and hopefully other opportunities that come will be where you make commercial hay. My unsolicited 2c.
I really do care about copyleft and AGPL. It’s a political choice. I specifically chose it because I know from direct experience that big tech is allergic to it.
I actually don’t care about the commercial license. It’s more of an experiment for my own amusement than an actual attempt at building a commercial project.
If it inspires someone to build another one and we still end up with a better differ, I’m ok with that world. As long as the open source community has a better differ.
Note that there already are at least 3 that I am aware of. But they do perform worse on speed and accuracy.
FWIW, there's probably no point in using a copyleft licence if AI is involved[1][2], unless you've got pretty solid proof AI only "assisted" rather than doing the bulk of the work. Otherwise, you don't have copyright on the generated code, and without copyright the licence is meaningless, AFAIK.
This is not to say you can't or shouldn't use AI, but it's important to understand the tradeoffs you're making.
I’m not based in the US so SCOTUS doesn’t set meaningful precedent for my IP.
That said, even under those rules, I would be comfortable arguing before the court that this code has significant human involvement and easily passes the copyright standard.
It’s also why I don’t think someone can just easily create another one and license it under BSD. My code is AI assisted, but all truly important pieces were human made.
> It’s also why I don’t think someone can just easily create another one and license it under BSD. My code is AI assisted, but all truly important pieces were human made.
Get one AI to describe what the code does, and another to implement based on that description. You might even get away with a human doing one of the steps. A variation of the classic “clean room reverse engineering” method that was used by Compaq to reimplement IBM's BIOS and start the clone PC market.
Some argue that “it doesn't work like that” but it certainly seems to be what some people are doing and as yet no one has been confident enough that their copyright extends through this mechanism that they've tested the theory in court.
Note: I'm not saying it is right, but that it might well be perfectly legal. It is definitely possible, practical even. I'd still release stuff under AGPL/similar for the same reasons stated above, but I'd not operate under any illusion that I'd be safe from someone using that method to copy everything they wanted to.
If an individual went through all this effort just to release it under MIT, I’d honestly be mostly just surprised someone cared so much. I’d probably just send them my own project relicensed under MIT out of pure curiosity.
But I am counting on the fact that _companies_ would be too worried about legal uncertainty to try this.
> I am counting on the fact that _companies_ would be too worried about legal uncertainty to try this
Oh, my sweet summery child :-)
Companies have been doing far more dodgy things, things that look objectively illegal where-as the clean-room reverse engineering thing looks to me (caveat: not a legal expert at all) to be legally defensible, for a long time, definitely pre-AI.
Even if a company operating in your jurisdiction, where you as an individual might have a cat in hell's chance of even trying to sort the situation to your preference, might not, you can bet your last <currency unit> that a company elsewhere will feel more free to do so if they wanted what you have without agreeing to your terms.
I’m perfectly happy to defend the copyright in the EU/EFTA and CAN/US.
If it’s a small company, it’s not worth it, but then again they are not causing a lot of damage either. If it’s a big company, they will find me unexpectedly resistant to usual legal bullying tactics. I have legal insurance, multiple lawyers as friends and don’t have a job so have loads of time for filing paperwork.
I support the choice of AGPL. I wish more software used it.
Whenever I use AI to write code, in my experience it invariably chooses the MIT license. For example, for all the ansible roles that I've written using AI it put the MIT license in the meta file, unless otherwise prompted. It makes me wonder if it comes from RLHF.
> Meanwhile, some other projects will take the core idea of "language aware differ" and release BSD, and one of those will win, including perhaps making it into git/future version controls.
Diffsitter and Difftastic have been around for a while, both MIT, so I doubt it.
> I am not super set on that value, if the community has a better default for “wide”, happy to modify it.
I feel like since terminal widths "classically" (when dinosaurs like me originally started coding) topped out at 79/80 columns wide, and thus why many code "style guides" still to this day suggest a code line-length of around 80-ish (to ensure that code lines "fit" on any terminal), I'd say maybe double-ish that might count as a good "wide" value? Say 160-ish? Meet or exceed that width to be considered "wide" by default?
Also, maybe a command-line switch, env variable, and/or config value to set it manually to some other user-preferred default value? Then I could set some arbitrary width like 128 or 256 if I like powers of two or somesuch silliness? :)
This looks really good. It does look like you put a ton of effort into it, I'll give it a try.
I feel like the moved code cases would look great in https://github.com/andunieee/twain, I was looking into how I could slurp your code and make it work there (although for some reason I have the impression that I had already seen this repository in the past, I can't remember where).
I don't know what I did wrong, but using this as a git difftool (following the config) I didn't get any of the cool things from the demos, I got a weird single-column diff output that only showed the new side of the changes, not a diff.
If I understand your goal correctly, you are looking to especially focus on the visual part of the diff and provide a nice UI for it, and you would like to use OmniDiff as a library?
If so, then let's talk. I have been delaying the design of the API because nobody has a use for it yet, so it is mostly driven by the needs of the CLI/TUI at the moment.
I had the same problem. v switched to the side-by-side view, but it wasn't listed in the help screen so I didn't know to use it till I read your comment.
I tried using this as configured with `omnidiff git configure`, but when I use `git difftool` it shows me the entire file in the TUI and I have to scroll down to where diff is. Is this intended behavior? Setting `--context` seems to have no effect.
I am sorry, I looked through the examples and I am not sure I prefer the output of omnidiff... Seeing how everyone else over here is instead overly enthusiastic makes me feel extremely dumb :D
Don't feel dumb. You are just an outlier on the visual preferences.
I actually do TWO solutions for each test case: a minimal diff and a maximal diff. Pressing 'm' in the TUI pops up a settings page where you can choose how the diff works.
I am actively researching how many ways there are to "paint" the same diff and user preferences and non-uniqueness of diffs is something I am super interested in.
If you would like to, it would be super useful for me to know what diff you don't like and why. It would help make the diff better for users with different visual preferences.
I'm a little confused on that, since in other comments you've mentioned that AGPL was a deliberate choice for <reasons>. So, what's the definitions of "winning" here?
Hi! as a developer, I personally prefer it when the libraries/tools used in my projects are GPL or another Copyleft license. The drove of MIT projects from the past decade has been depressing.
The default git diff uses the Myers diff algorithm as implemented in xdiff. It's a line based diff with some pre and post processing for better results.
The move detection is a post-processing step that only works on lines and additionally only works if you also enable coloured output.
It can't match "moved-but-eddited" code and it can't match "this one log line was copied 3 times in the new code" or the refactoring equivalent "these 2 blocks of code were merged into one reusable function".
You have to use more syntax-aware algorithms to get true move detection. OmniDiff matches the nodes of the AST to get some of that syntax awareness.
You know hebetube, my mother once said "if you have nothing nice to say: don't say it". You saying those things probably aren't going to make them turn over the license. "Project dead before it started" like who writes those kinds of things over someones work they spent time on. I'd love for you to explain your logic.
It would be nice if you checked out lazygit and consider adding support to it's recently added OSC1717, adding supporting for staging in the main diff view directly: https://github.com/stefanhaller/diff-line-metadata-spec
Also it would be nice to have a more thorough and comprehensive comparison against difftastic, because I don't think there are much, or even any difference to code diffing compared to it: https://ivankovic.github.io/omnidiff/showcase/
Does yours support move + change detection across different files, like A/before.rs => B/after.rs (~some changes)?
Feel free to subscribe to https://github.com/ivankovic/omnidiff/issues/62 to get notified when Lazygit support is added.
An extremely thorough comparison against difftastic is in the research/ directory. I don't recommend reading it, unless you are really into diffs. Even describing the dataset takes a good half an hour.
Multi-file support is on the roadmap. Subscribe here: https://github.com/ivankovic/omnidiff/issues/63
How does it compare to Difftastic[1]? Both built on top of TreeSitter and solve similar problems.
[1] https://difftastic.wilfred.me.uk/
Comparing is slightly complicated but roughly speaking:
Difftastic only diffs code, which is only 2/3 of all diffs.
When only measured on stuff difftastic supports:
Difftastic is perfect on 64% of diffs and near-perfect on 17% more.
Omnidiff is perfect on 90% of diffs and near-perfect on 5% more.
Speed is
p50 - 35ms difftastic vs 4ms OmniDiff p99 - 637ms vs 420ms
Difftastic is MIT vs AGPL.
> Difftastic is perfect on 64% of diffs and near-perfect on 17% more.
> Omnidiff is perfect on 90% of diffs and near-perfect on 5% more.
I did not find examples in the repo or any way to test what "perfect" or "near perfect" in those cases mean. On the playground you compare against unix diff only. Based on my quick comparisons with difft, I do not see much difference. Could you add a link to comparisons or show how it differs and what are those numbers based on??? I'm not dismissive, just looking for a proof or showcase.
It’s in the research/ directory.
Fair warning: the true comparison is fairly complex and doesn’t really lend itself to “quick comparison”.
Also, the research is NOT complete.
> Difftastic only diffs code, which is only 2/3 of all diffs.
Care to elaborate? What does Omnidiff offer for non-code files?
https://ivankovic.github.io/omnidiff/showcase/content.html
Note that you do need a terminal with image support, like kitty, alacritty.
If you do not have image support, it does its best with image2ascii, but it is obviously severely limited.
Wow.. that looks great
For me the biggest issue is “git rebase” merge conflicts because the surrounding context was modified (especially near beginning/end of functions where the context includes unrelated stuff), or similar in a markdown document.
(If commit A adds a line to the end of a bullet list in markdown and commit B does the same, they will conflict even though resolution is trivial for a human)
You could try https://mergiraf.org/
For me the answer to painful merge conflicts has been... Claude
Not sure why you're getting downvoted. I haven't resolved conflicts by hand in almost a year.
the resolution depends on a deeper understanding of the contents of the list and whether they are ordered according to some scheme (in which case you will need to look at the two lines and see which one goes first)
Resolution is ambiguous without context. The most trivial example: does order matter? If so, which goes first?
That would also be trivial for a syntax-tree-based tool, right?
Nicely done OP. Does it do 3-way diffs for merges as well? The instructions only mention the two-way `git difftool` configuration so maybe that'll be a future feature?
Any interest in getting the setup upstreamed[1] so that users only need to `git config --global diff.tool omnidiff` to enable it by default? Disclosure: I created `git difftool` a long time ago, and am always happy when builtin support for useful tools are added to it. Feel free to reach out if you'd like help making that happen.
[1] https://github.com/git/git/tree/master/mergetools
At the moment the algorithm for code diffing is a particularly efficient implementation of APTED which is a tree diffing algorithm that doesn’t natively construct anything useful for a three way diff. I have a notebook with a bunch of failed attempts at a good algorithm for a three way merge, but so far nothing particularly impressive.
It’s a long term goal to solve, but it’s the hardest one.
I’ll definitely reach out to you to upstream. Thank you for the kind offer!
How do you handle degenerate trees? I’m curious what heuristics are used in practice to eg backtrack or whatever. I’m not very well versed in TED but superficially the problem seems to resemble wave function collapse.
It’s a 5 step pipeline.
In practice, tree hashing is doing a huge amount of work because most diffs are tiny. Half of all diffs are less than 10 lines, so a hash can extremely quickly match large subtrees.
In a profoundly degenerate case of a C++ header file with only a 20MB array of bytes, it detects a degenerate tree and uses Myers O(N) sequence diffing algorithm instead of treating it as a tree.
How would one craft an input that maximizes the runtime of your diff while staying below some (reasonable) bound of edit distance apart? Basically suppose I wanted to provide a malicious diff designed to hang or timeout the diff program, how would I construct it?
You need to maximize the size of the residual tree sent to the final APTED step.
I actually don’t know how to do that and stay under a bounded edit distance.
Alternatively, you can crash it if you just encode the entire “Star Trek - In the pale moonlight” episode as a sequence of bytes in a const int array in C++.
> I actually don’t know how to do that and stay under a bounded edit distance.
I’m sure there’s an interesting result there, but I am not the person to find it :D
Good episode btw
> can diff 99.95% of code changes
I’m not sure if I’m understanding this correctly : so for the remaining 0.05% of code changes, this tool would just… miss it? That seems horrible for a diff tool :O
It will crash.
But so will every other tool, because it is things like a C++ header file with 128MB of PNG data hardcoded as an array.
Editors don’t even open those files.
Fair enough.
But then I would rephrase that because it's confusing, and not doing justice to your tool.
Good point.
Thanks!
Perhaps it could just check the length of files and not crash?!? Don’t you think that’s sensible?
It's a tradeoff. The length itself is not a problem. It will happily diff normal multi-MB files.
The problem is the degenerative syntax tree that TreeSitter produces in case of, for example a multi-million array of bytes. This causes a stack overflow in the TreeSitter C code which takes down the Rust process with it.
The correct solution would be to prevent TS from crashing, or isolate the C<->Rust boundary better.
Or just, not support that for v0.3. Because if you are diffing the collected works of Shakespeare as a binary blob in a C++ header, maybe diffing isn't your biggest problem.
> Editors don’t even open those files.
vi opens multi-GB files just fine.
And for multi-TB files, "less -n" works.
You need to broaden your horizons about editors. Not all of then are javascript-based slopfests
The crash will happen in TreeSitter which is a widely used AST library that all modern editors, including neovim, depend on for syntax highlighting and which is also used by many LSPs.
Additionally, here's an appropriate XKCD: https://xkcd.com/378/
Please demonstrate that crash on “less -n” or vim with no plugins. I just happily opened a multi gb file in both. No issue
As soon as you demonstrate editing a file with less :)
Delta has a really nice way to show diffs with its diff-so-fancy mode, it's more similar to GitHub's UI where not only the line is colored up differently but there's a different shade of color to highlight the characters.
There's a screenshot and video of it here that I wrote a while back: https://nickjanetakis.com/blog/awesome-git-diffs-with-delta-...
In OmniDiff's readme and web version I didn't see a way to do that.
In a different comment you mentioned OmniDiff is much better than Delta and you mentioned "About a third of diffs are significantly better.". Can you provide some examples of these? I've never seen Delta fail a diff.
Also Delta has a package for Arch in its official repos. For folks who just want a "it works" experience, that's a pretty big win. With Delta the same package can be installed in the same way on Debian, Arch and macOS with Brew using standard package managers. With OmniDiff, there's 3 different ways to install it (manual deb package on Debian, manual package compile on Arch and brew install on a Mac). Just something to think about, as someone who has public dotfiles that work in those 3 environments, I'd skip OmniDiff based on this alone.
OmniDiff is character based by default. It will only highlight the changed characters. I suppose I could add an option to additionally highlight the line as well. Thanks for the feedback!
As for packaging. Unfortunately AUR is closed at the moment due to spam. I can add brew commands for Linux, happily.
In terms of “better”. It’s actually somewhat complex, but a simple way to think about it is that if you move a function up or down in the same class, text-based diffs paint that as “Deleted here, Inserted there” where ideally you would want it to say “Moved”.
Is there a way to use it with git without having to change your global git config? I.e. `git diff | omnidiff` or something?
You can do this with delta: `git diff | delta --side-by-side`
https://github.com/ivankovic/omnidiff#usage
Piping the output of `git diff` might withhold information from the tool that it needs for its feature set, while `delta` is just a different way to display any diff output.
cool to see fresh Rust software with copyleft license !
I feel safer, as a user, enjoying the freedoms that the AGPL provides me. (No evil middleman will be able to give me non-free versions of this program.)
But an evil midllman will relatively easily be able to give you non-free version, so that feeling should be fleeting
As long as they open source all modifications and follow AGPL to the letter so that anyone can self-host the version they are selling, I’m ok with that.
AGPL totally allows commercial use. You just have to give back.
So much this. Thanks OP!
Wow, I've often wished I had a tool like this. Thanks!
Since most people do click-and-run most of the time (based on decades long research, n=1), I'll just add paste the link for more examples: https://ivankovic.github.io/omnidiff/showcase/content.html
And this: https://ivankovic.github.io/omnidiff/showcase/index.html?cas...
You have a good core idea here. You're pretty much killing your project in infancy with the AGPL+donation license model. Meanwhile, some other projects will take the core idea of "language aware differ" and release BSD, and one of those will win, including perhaps making it into git/future version controls.
IMO, you should seek to make this a standard that wins, and hopefully other opportunities that come will be where you make commercial hay. My unsolicited 2c.
I really do care about copyleft and AGPL. It’s a political choice. I specifically chose it because I know from direct experience that big tech is allergic to it.
I actually don’t care about the commercial license. It’s more of an experiment for my own amusement than an actual attempt at building a commercial project.
If it inspires someone to build another one and we still end up with a better differ, I’m ok with that world. As long as the open source community has a better differ.
Note that there already are at least 3 that I am aware of. But they do perform worse on speed and accuracy.
FWIW, there's probably no point in using a copyleft licence if AI is involved[1][2], unless you've got pretty solid proof AI only "assisted" rather than doing the bulk of the work. Otherwise, you don't have copyright on the generated code, and without copyright the licence is meaningless, AFAIK.
This is not to say you can't or shouldn't use AI, but it's important to understand the tradeoffs you're making.
[1] https://www.scotusblog.com/cases/thaler-v-perlmutter/ [2] https://www.jenner.com/en/news-insights/client-alerts/us-cop...
I’m not based in the US so SCOTUS doesn’t set meaningful precedent for my IP.
That said, even under those rules, I would be comfortable arguing before the court that this code has significant human involvement and easily passes the copyright standard.
It’s also why I don’t think someone can just easily create another one and license it under BSD. My code is AI assisted, but all truly important pieces were human made.
> It’s also why I don’t think someone can just easily create another one and license it under BSD. My code is AI assisted, but all truly important pieces were human made.
Get one AI to describe what the code does, and another to implement based on that description. You might even get away with a human doing one of the steps. A variation of the classic “clean room reverse engineering” method that was used by Compaq to reimplement IBM's BIOS and start the clone PC market.
Some argue that “it doesn't work like that” but it certainly seems to be what some people are doing and as yet no one has been confident enough that their copyright extends through this mechanism that they've tested the theory in court.
Note: I'm not saying it is right, but that it might well be perfectly legal. It is definitely possible, practical even. I'd still release stuff under AGPL/similar for the same reasons stated above, but I'd not operate under any illusion that I'd be safe from someone using that method to copy everything they wanted to.
If an individual went through all this effort just to release it under MIT, I’d honestly be mostly just surprised someone cared so much. I’d probably just send them my own project relicensed under MIT out of pure curiosity.
But I am counting on the fact that _companies_ would be too worried about legal uncertainty to try this.
> I am counting on the fact that _companies_ would be too worried about legal uncertainty to try this
Oh, my sweet summery child :-)
Companies have been doing far more dodgy things, things that look objectively illegal where-as the clean-room reverse engineering thing looks to me (caveat: not a legal expert at all) to be legally defensible, for a long time, definitely pre-AI.
Even if a company operating in your jurisdiction, where you as an individual might have a cat in hell's chance of even trying to sort the situation to your preference, might not, you can bet your last <currency unit> that a company elsewhere will feel more free to do so if they wanted what you have without agreeing to your terms.
I’m perfectly happy to defend the copyright in the EU/EFTA and CAN/US.
If it’s a small company, it’s not worth it, but then again they are not causing a lot of damage either. If it’s a big company, they will find me unexpectedly resistant to usual legal bullying tactics. I have legal insurance, multiple lawyers as friends and don’t have a job so have loads of time for filing paperwork.
You are assuming OP is in the US.
Though AI code copyright is an unknown pretty widely either way, it's too new for the legal system to have caught up with it yet.
The CH in FabCH stands for Switzerland :)
… we don’t know what to do with AI copyright either. I assume a referendum will sort it out at some point.
I support the choice of AGPL. I wish more software used it. Whenever I use AI to write code, in my experience it invariably chooses the MIT license. For example, for all the ansible roles that I've written using AI it put the MIT license in the meta file, unless otherwise prompted. It makes me wonder if it comes from RLHF.
> Meanwhile, some other projects will take the core idea of "language aware differ" and release BSD, and one of those will win, including perhaps making it into git/future version controls.
Diffsitter and Difftastic have been around for a while, both MIT, so I doubt it.
An idea you can steal: turn common generated/lockfile diffs into something readable (a la https://www.npmjs.com/package/diff-package-lock)
https://github.com/ivankovic/omnidiff/issues/61 feel free to subscribe to the issue to see when it is done.
Really well done, I like this a lot. It produces much more minimal diffs than other tools I've tried.
One feature I miss from difftastic is showing diffs side-by-side on wide terminals, and unified when narrow.
It should… it considers wide to be 200+ columns.
You can force it with “v”.
I am not super set on that value, if the community has a better default for “wide”, happy to modify it.
> I am not super set on that value, if the community has a better default for “wide”, happy to modify it.
I feel like since terminal widths "classically" (when dinosaurs like me originally started coding) topped out at 79/80 columns wide, and thus why many code "style guides" still to this day suggest a code line-length of around 80-ish (to ensure that code lines "fit" on any terminal), I'd say maybe double-ish that might count as a good "wide" value? Say 160-ish? Meet or exceed that width to be considered "wide" by default?
Also, maybe a command-line switch, env variable, and/or config value to set it manually to some other user-preferred default value? Then I could set some arbitrary width like 128 or 256 if I like powers of two or somesuch silliness? :)
This looks really good. It does look like you put a ton of effort into it, I'll give it a try.
I feel like the moved code cases would look great in https://github.com/andunieee/twain, I was looking into how I could slurp your code and make it work there (although for some reason I have the impression that I had already seen this repository in the past, I can't remember where).
I don't know what I did wrong, but using this as a git difftool (following the config) I didn't get any of the cool things from the demos, I got a weird single-column diff output that only showed the new side of the changes, not a diff.
Ok I had a deeper look at twain now.
If I understand your goal correctly, you are looking to especially focus on the visual part of the diff and provide a nice UI for it, and you would like to use OmniDiff as a library?
If so, then let's talk. I have been delaying the design of the API because nobody has a use for it yet, so it is mostly driven by the needs of the CLI/TUI at the moment.
Ping me on my email if you want.
Perhaps the terminal is too small? What happens when you hit tab or “v”?
I had the same problem. v switched to the side-by-side view, but it wasn't listed in the help screen so I didn't know to use it till I read your comment.
I tried using this as configured with `omnidiff git configure`, but when I use `git difftool` it shows me the entire file in the TUI and I have to scroll down to where diff is. Is this intended behavior? Setting `--context` seems to have no effect.
Press “n“ or “p” to jump to next/previous difference.
Press ? for the help menu.
I'd be curious how it compares to BeyondCompare by Turtle Software. I've always been really impressed with their diffs and 3-way merges.
Unfortunately that is a comparison I will not be doing because BeyondCompare is paid closed-source software.
There's a free trial.
I am sorry, I looked through the examples and I am not sure I prefer the output of omnidiff... Seeing how everyone else over here is instead overly enthusiastic makes me feel extremely dumb :D
Don't feel dumb. You are just an outlier on the visual preferences.
I actually do TWO solutions for each test case: a minimal diff and a maximal diff. Pressing 'm' in the TUI pops up a settings page where you can choose how the diff works.
I am actively researching how many ways there are to "paint" the same diff and user preferences and non-uniqueness of diffs is something I am super interested in.
If you would like to, it would be super useful for me to know what diff you don't like and why. It would help make the diff better for users with different visual preferences.
[dead]
Very cool! I'd love to see support for figma or Photoshop, perhaps it's already possible via export to an image format, but native would be cool.
Depending on how proprietary their formats are, it could be done.
How does it compare with diffstatic?
Comparing is slightly complicated but roughly speaking:
Difftastic only diffs code, which is only 2/3 of all diffs.
When only measured on stuff difftastic supports:
Difftastic is perfect on 64% of diffs and near-perfect on 17% more.
Omnidiff is perfect on 90% of diffs and near-perfect on 5% more.
Speed is
p50 - 35ms difftastic vs 4ms OmniDiff p99 - 637ms vs 420ms
Difftastic wins on license. MIT vs AGPL.
> Difftastic wins on license. MIT vs AGPL.
I'm a little confused on that, since in other comments you've mentioned that AGPL was a deliberate choice for <reasons>. So, what's the definitions of "winning" here?
It was a tongue-in-cheek joke :)
But it was worth pointing out the difference in license, it is one of the ways in which the projects differ.
The more permissive MIT is often an advantage if you want to build it into something bigger, which is reasonable for diff tool.
Discrete users would arguably win more with integrity of AGPL, but developers have reasons to prefer MIT.
> but developers have reasons to prefer MIT
Hi! as a developer, I personally prefer it when the libraries/tools used in my projects are GPL or another Copyleft license. The drove of MIT projects from the past decade has been depressing.
Servitude to their masters
How is it better or worse compared to https://github.com/dandavison/delta ?
It’s much much better with moved code.
Delta adds color to the standard git diff algorithm.
Omnidiff uses a completely different algorithm.
About a third of diffs are significantly better.
> It’s much much better with moved code. > Delta adds color to the standard git diff algorithm.
Git will highlight moved code and delta shows that, so how does OmniDiff differ from
Partially.
The default git diff uses the Myers diff algorithm as implemented in xdiff. It's a line based diff with some pre and post processing for better results.
The move detection is a post-processing step that only works on lines and additionally only works if you also enable coloured output.
It can't match "moved-but-eddited" code and it can't match "this one log line was copied 3 times in the new code" or the refactoring equivalent "these 2 blocks of code were merged into one reusable function".
You have to use more syntax-aware algorithms to get true move detection. OmniDiff matches the nodes of the AST to get some of that syntax awareness.
Do you have any examples illustrating how it's better?
Okay, I'll give it a try then.
Older submission: https://news.ycombinator.com/item?id=49891989
Not quite.
In the meantime, I added support for all other non-code file formats. Hence the name change.
It’s quite a big chunk of functionality.
can it diff word files?
Depends on what exactly you mean by word files and what exact format is used.
It will diff OpenOffice compatible files.
[flagged]
[dead]
[flagged]
[dead]
[dead]
[flagged]
[flagged]
> with licenses nobody wants to use
Nobody wants to use AGPL-v3?
https://github.com/ivankovic/omnidiff/blob/main/LICENSE
Some people think there's no point if you're not allowed to steal the code and not give back
How can one be allowed to steal something? Then it is by definition not stealing.
You know hebetube, my mother once said "if you have nothing nice to say: don't say it". You saying those things probably aren't going to make them turn over the license. "Project dead before it started" like who writes those kinds of things over someones work they spent time on. I'd love for you to explain your logic.