jupyterlab-gitplus VS difftastic

If you are in need of a diff tool for jupter notebooks use https://www.reviewnb.com/ and for word documents use https://www.simuldocs.com/

- GitHub PR code reviews with ReviewNB[4]

Alternatively, if you don't care about cell outputs then Jupytext[5]

Disclaimer: I built ReviewNB. It's a completely bootstrapped business, 5 years in the making and now used by leading DS teams at Meta, AWS, NASA JPL, AirBnB, Lyft, Affirm, AMD, Microsoft & more (https://www.reviewnb.com/#customers)

[1] https://github.com/jupyterlab/jupyterlab-git

Already a GitHub plugin that does this very nicely: ReviewNB

For version control: https://www.reviewnb.com/ helps. Agree with the rest but some experimental notebooks are useful to track/version control.

It's not focused on collaboration, but it does add some critical pieces that otherwise make Jupyter development frustrating when working with a team. Specifically: `nbdev_prepare` ensures that diffs are as small as possible, by removing and standardising notebook metadata; and `nbdev_fix` fixes merge conflicts so that they are cell-level, rather than line level, so they can be opened and fixed in notebooks.

Something else we've found helpful for collaboration (not associated - just happy users) is this: https://www.reviewnb.com/ . It means we can get a nice notebook-based PR workflow.

Real-time collaboration is available in Jupyter nowadays: https://jupyterlab.readthedocs.io/en/stable/user/rtc.html . nbdev doesn't have any extra functionality for it, however -- but it should work fine in this environment.

i want a diff tool that shows me exactly which tokens have changed, and which haven't, regardless of how they are laid out.

These already exist: https://github.com/Wilfred/difftastic

when we get that, then we should get even less merge conflicts.

Counterintuitively, that is not the case. AST-merge is a much, much, much, much, much harder problem than AST-diff.

https://github.com/Wilfred/difftastic?tab=readme-ov-file#can...

The fact that diffs can be used to drive a 3-way merge is in fact an accidental property that arises due to the sheer crudeness of the diff format. As soon as you start using more-sophisticated diff formats, solutions to "the diff problem" no longer lead directly to solutions to "the merge problem".

Yes there is an `—-override` option you can use to specify the language in which a file should be parsed.

https://github.com/Wilfred/difftastic/blob/master/CHANGELOG....

Use the fantastic difftastic instead of git's diff. https://difftastic.wilfred.me.uk/

  [alias]

difftastic provides similar capabilities in a free tool based on treesitter

difftastic? https://github.com/Wilfred/difftastic

If you're looking for a VS Code extension or a GitHub app, check out https://semanticdiff.com/. I'm a co-founder of this project.

If you prefer a CLI tool, check out https://github.com/Wilfred/difftastic. It supports more languages, but doesn't recognize when code has been replaced by an equivalent version ("invariances"). So it will show some changes (e.g. replacing a character in a string with an escape sequence) even though they are technically equivalent.

Shameless plug: I've written difftastic[1], a tool that builds ASTs and then does a structural diff of them. You can use it with git too.

It's an incredibly hard problem though, both from a computational complexity point of view, and trying to build a comprehensible UI once you've done the structural AST diff.

[1]: https://github.com/wilfred/difftastic

There is a diff tool called difftastic: https://github.com/Wilfred/difftastic

The idea is that it does not show diff based on text change, but on syntastic meaning. For that, it uses tree-sitter.

I think it still shows the trailing comma in the situation as shown in the article, but it's quite different experience than the standard text based diff.