As the years go by, I find myself increasingly in the minority of those who still prefer the unified diff view.
My favourite tool for diffing has always been “diff -u”. I sometimes even use “diff -U10000” when I want to see the entire file as context.
Thankfully, GitHub still supports unified diff view, so I don’t feel left out while reviewing GitHub pull requests.
In fact, once upon a time, when there was no GitHub or GitLab and there were no “pull requests”, open source developers used to email each other .diff files (often also named .patch files) which were nothing but unified diff files. A reviewer would apply the patch on their copy of source code with something like “patch -p0 < new.diff” and test it locally on their system. That was the CI of that era.
> As the years go by, I find myself increasingly in the minority of those who still prefer the unified diff view.
Wait, so what does the majority prefer these days then? I might be out of the loop, last time I checked (which was today) git still defaulted to unified diffs.
I've been using meld, also didn't see any ads in it yet. I didn't realize defaulting to websites for diffing was a thing. The closest thing I know to that is github pull requests, which also show no ads afaik.
Nothing against the littlediffer project, I just really wonder what ad-ridden diff tools the title would be referring to
I was about to drop into my spiel about “it isn't so much the adverts that bother me about web-based things, it is the stalky tracking”. Though after checking I was pleasantly surprised to find it doesn't make a pile of third-party requests as some ad-free-but-still-part-of-the-stalkerverse sites do.
I don't really trust such tools unless I host them myself (in DayJob I'm not allowed to trust such tools, lest I accidentally paste information about clients' people/customers into a site that posts the data out of the country) but at least this one is starting out OK, so congratulations to the creator for making something working and clean (even if it is ultimately of limited use as local tools work much better for this purpose).
It is sad that “without stalkyness and other unnecessary bulk & distractions” isn't the norm (even for desktop utilities too often) so can be pointed out as a special feature, but that is the world we live in…
I haven't known that I need a browser to diff two files. I always did that in the terminal, local only. Didn't know that we need some many comupting time to create a diff. /s
I'm the creator of this tool. There are some interesting points here so I wanted to clarify: I made it for those times when I'm in the middle of a PR review and I just want to diff two things really quickly. Sure I can create two temp files and diff them using the terminal, or in my IDE. But I wanted something more convenient.
I usually wind up in a web-based tool and they're mostly ridden with ads and very un-slick UIs.
I hope you find this helpful, I've been using it for a year and decided to just publish it.
I use these kind of sites quite often. I just find them more convenient. It's also way easier to instruct a layman to use a website like that than tell them to use the command line tool.
sometimes I diff content that is just part of local files, or a local and remote file etc.. I don't want to clean-up to files for a diff to be readable.
Having a simple web-based copy-paste diff-tool is extremely valuable to me!
Who is the audience that need to diff file but choose to do it by copy pasting in a web browser rather than in their editor directly or using one a diff tool in command line, none of which has ever shown any ads?
I’ve been telling myself never to speak out about “couple of” adblockers. Now, I know I’m not the only one. Blocking at the DNS + Client is just the starting base. Thanks.
My favourite tool for diffing has always been “diff -u”. I sometimes even use “diff -U10000” when I want to see the entire file as context.
Thankfully, GitHub still supports unified diff view, so I don’t feel left out while reviewing GitHub pull requests.
In fact, once upon a time, when there was no GitHub or GitLab and there were no “pull requests”, open source developers used to email each other .diff files (often also named .patch files) which were nothing but unified diff files. A reviewer would apply the patch on their copy of source code with something like “patch -p0 < new.diff” and test it locally on their system. That was the CI of that era.
reply