Awesome-Rust-MachineLearning VS delta

There’s an awesome-git list for a bunch of ML rust stuff not sure how up to date it is as well https://github.com/vaaaaanquish/Awesome-Rust-MachineLearning … not mine

I am looking for something like [Triton Inference Server](https://github.com/triton-inference-server/server) or [TFX Serving](https://www.tensorflow.org/tfx/guide/serving), but in Rust. I came across [Orkon](https://github.com/vertexclique/orkhon) which seems to be dormant and a bunch of examples off of the [Awesome-Rust-MachineLearning](https://github.com/vaaaaanquish/Awesome-Rust-MachineLearning)

There's also https://github.com/vaaaaanquish/Awesome-Rust-MachineLearning

I saw Awesome-Rust-MachineLearning. It have something replacements from Python.

delta | Github

You can also do that with delta (https://github.com/dandavison/delta), with additional options that you can put on your .gitconfig

https://github.com/dandavison/delta/issues/364 https://github.com/dandavison/delta https://dandavison.github.io/delta/full—help-output.html

Thanks! https://github.com/dandavison/delta/pull/1893

> To automatically display the light or dark version of images depending on their gh theme

Ah, good call. That could be a nice improvement -- creating light and dark versions of the screenshots with switching as you describe.

As someone who also uses Git exclusively from the command line, without any TUI wrappers, I agree with a lot of this. The parts about commits being revertable, bisectable and in general _atomic_ are very important, and IME the only correct way of using version control.

One exception: conventional commits. I find them very useful even on solo projects, since a) they make it easy to spot the type of change at a glance, and b) they force me to keep commits atomic. That is, if I'm ever compelled to make a commit that is both a `fix` and a `refactor`, usually out of laziness :), sticking to a conventional commit message is a quick way to determine what needs to be split into a different commit. These conventions really shine when used in a team, as they improve communication and keep the history tidy (along with all other benefits of atomic commits), but so far I haven't had the luck to work on teams that agree to adopt this workflow. Using these commits to generate changelogs would be wrong, as changelogs should almost never be autogenerated (though these days maybe AI does an acceptable job at it), but they're still useful to keep track of the number of fixes, features, etc. that were produced in a release.

And a tip: in addition to plain shell and Git aliases, I've found scmpuff[1] and delta[2] to be invaluable in a Git CLI workflow.

[1]: https://mroth.github.io/scmpuff/

[2]: https://github.com/dandavison/delta

https://github.com/dandavison/delta is nice for a prettier presentation of the same information as `git diff`.

This may or may not qualify, since I think GNU diff supports it with an option, as does Git diff, but "Color-words" diff can be nice, where changes in the middle of the line are highlighted and whitespace is ignored.

Somebody already recommended https://github.com/Wilfred/difftastic, which I second. It uses treesitter and is very interesting. Surprisingly, in practice difftastic is not always noticeably better than color words diff (don't expect miracles), but occasionally it is much better.

`git blame` lets you identify the commit that changed the line you’re looking for, but doesn’t make it easy to then view further details. The author might prefer GitHub’s blame view because it has these features:

• each hunk has a link to the commit that changed it, as opposed to needing to copy a line’s SHA and then run a new `git show …` command

• each hunk has a link to view the `blame` as of that older commit, as opposed to needing to copy a line’s SHA and then run a new `git blame … path/to/file` command

• the code is syntax highlighted by default, without you needing to configure your local Git install to use https://github.com/dandavison/delta

These features lead to a better experience than `git blame`. Various IDEs, editor plugins, TUIs, and GUIs provide similar features.