Which difftool
do you use and why? I develop on Windows and I use KDiff3. It has worked flawlessly all these years. And just because of that I haven’t really followed what else is out there. I suspect I’m in the minority?
deleted by creator
Beyond Compare is a solid tool. I remember one of my colleagues using it many moons ago. I’m not surprised they are still going strong. And the fact that they haven’t switched to a subscription model says a lot about the company. But as the FOSS tools get better, I expect they may have difficulty keeping their user/customer base.
I’m a vim user so naturally I use vim. I have the fugitive plugin which is a relatively thin wrapper around git commands and mostly run
:Git difftool -y
when I wanna go through the diffsHonestly, this should have been my answer. I’m a vim person and I have fugitive installed, I’ve just never taken the time to learn how to use it fully.
I was in the same situation until like a year ago. I can recomend browsing through the documentation!
I mostly use
:G
as an interactivegit status
,:Git difftool -y
to look through my changes before commiting and:Gdiffsplit
to diff the current file. Also instead of doing e.g.:!git pull
I’d do:Git pull
and so on. It’s nice because most commands are just the same as on the command line, so the knowledge is mostly transferable, but doing them in vim requires less context switching.Thanks for the pointers, I’ll try to start using it more.
For terminal, I use delta - it provides nice visual deltas.
For GUI I just use vscode. Select file 1, ctrl-LMB file 2, RMB on file 2 -> compare files.
If, for some reason, I have to compare whole folders (at least on windows), I’ll use WinMerge (it can also compare folders to globally check for file differences, without going directly into specific changes) for folder and files comparisons.
I have two.
- For CLI only: diff-so-fancy
- For regular use: Fork
I prefer Fork since it’s stupidly easy to rebase, and it’s stupidly easy to stage by line instead of by file. This lets me split my changes into different logical commits which makes reviewing those changes back so much faster.
I can’t help but cringe when I see devs add every change to a single commit instead of separating their changes.
Being able to stage only specific lines of files allows you to finalise one part of your changes that you know are finished, while you’re still half way through with your other change.
What’s easier to read?
Branch 1 (the commit everything in a file approach):
- Added changes
- Fixed bug
Branch 2 (the commit the relevant lines approach):
- Feature: Show subscription/product information on checkout page
- Feature: Revise text
- Bugfix: Translate pop-up messages
- Chore: Remove debugging log
Now if I realise later on that the bugfix had an unintentional side effect, I can single out the bugfix by itself, and not need to figure out why debugging messages are getting sent, or why a whole bunch of variables in another spot were changed.
I’ve been using GitLens by gitkracken here lately with VS Code.
I use
meld
if it’s too much to manage in vim/neovim.I mostly edit the raw file too and also use
meld
for the tricky casesLove Meld. I use either it, or Intellij’s built-in diff tool.
meld
is great. I used to use it when I developed in Linux. I tried to get its Windows port to work, but failed.Ah, that sucks. I’ve only ever used it on Linux and Mac. I know it wasn’t officially supported on Windows, but figured somebody had gotten it working decently.
Tried it a couple of times. Will probably give it another go in my next setup (around autumn).