this post was submitted on 21 Jun 2023
5 points (100.0% liked)

Git

2937 readers
1 users here now

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

  1. Follow programming.dev rules
  2. Be excellent to each other, no hostility towards users for any reason
  3. 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.

founded 2 years ago
MODERATORS
Ategon
canpolat
jnovinger
5
git difftool (self.git)
submitted 2 years ago by canpolat to c/git
14 comments fedilink hide all child comments
 

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?

you are viewing a single comment's thread
view the rest of the comments
[–] spartanatreyu 3 points 2 years ago

I have two.

  1. For CLI only: diff-so-fancy
  2. 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.