Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why a user will opt to use klondiff instead of diff-so-fancy? #1

Open
jetm opened this issue Aug 30, 2018 · 2 comments
Open

Why a user will opt to use klondiff instead of diff-so-fancy? #1

jetm opened this issue Aug 30, 2018 · 2 comments

Comments

@jetm
Copy link

jetm commented Aug 30, 2018

https://github.com/so-fancy/diff-so-fancy

@jetm jetm changed the title Why a user will opt to use klondiff instead of diff-so-fancy> Why a user will opt to use klondiff instead of diff-so-fancy? Aug 30, 2018
@pierstitus
Copy link
Owner

Thanks for bringing that project under attention, I personally didn't know about it. I had a look at it, and it's definitely interesting.

The differences I see:

Klondiff consists of two tools, a new diff algorithm, and a fancy diff colorizer, while diff-so-fancy is a post-processor for git diff.

Klondiff excells in handling indentation changes, which is hard to do in post-processing.
Also it finds more matching lines, when the number of lines in a changed block are different diff-so-fancy doesn't seem to search for similarity.
Klondiff diffs are human readable, but also still valid machine readable unified diffs.

diff-so-fancy does reformat the metadata to remove stuff that's not so interesting for humans.
Also it uses more colors, like dark backgrounds. Those are not supported on tty terminals, but I guess those are quite rarely used for development nowadays.

I do like the way diff-so-fancy is implemented as a git pager, and it might make sense to do the same with the klondiff colorizer. Also supporting more colors would be nice.

@jetm
Copy link
Author

jetm commented Aug 30, 2018

@pierstitus Thank you for the response. You might want to add your response to the README.md file. I think it will be usefully as a selection criterion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants