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.
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 use
meldif it’s too much to manage in vim/neovim.I mostly edit the raw file too and also use
meldfor the tricky casesLove Meld. I use either it, or Intellij’s built-in diff tool.
meldis great. I used to use it when I developed in Linux. I tried to get its Windows port to work, but failed.
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 -ywhen 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
:Gas an interactivegit status,:Git difftool -yto look through my changes before commiting and:Gdiffsplitto diff the current file. Also instead of doing e.g.:!git pullI’d do:Git pulland 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.
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.
