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?

  • zygo_histo_morpheus
    link
    fedilink
    English
    arrow-up
    5
    ·
    2 years ago

    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

    • Jason NovingerM
      link
      fedilink
      English
      arrow-up
      2
      ·
      2 years ago

      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.

      • zygo_histo_morpheus
        link
        fedilink
        English
        arrow-up
        3
        ·
        2 years ago

        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.

    • canpolatOPM
      link
      fedilink
      arrow-up
      2
      ·
      2 years ago

      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.

    • canpolatOPM
      link
      fedilink
      English
      arrow-up
      3
      ·
      2 years ago

      meld is great. I used to use it when I developed in Linux. I tried to get its Windows port to work, but failed.

      • Jason NovingerM
        link
        fedilink
        English
        arrow-up
        1
        ·
        2 years ago

        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.

        • canpolatOPM
          link
          fedilink
          English
          arrow-up
          2
          ·
          2 years ago

          Tried it a couple of times. Will probably give it another go in my next setup (around autumn).

    • truami
      link
      fedilink
      English
      arrow-up
      2
      ·
      2 years ago

      Love Meld. I use either it, or Intellij’s built-in diff tool.

  • NostraDavid
    link
    fedilink
    English
    arrow-up
    3
    ·
    2 years ago

    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.

  • spartanatreyu
    link
    fedilink
    English
    arrow-up
    3
    ·
    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.