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 diffs
Git
Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
Resources
Rules
- Follow programming.dev rules
- Be excellent to each other, no hostility towards users for any reason
- No spam of tools/companies/advertisements. It’s OK to post your own stuff part of the time, but the primary use of the community should not be self-promotion.
Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License.
Honestly, 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 interactive git 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.
I use meld
if it's too much to manage in vim/neovim.
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).
I mostly edit the raw file too and also use meld
for the tricky cases
Love Meld. I use either it, or Intellij's built-in diff tool.
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.
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.