33

I used to use Windows, SVN, Tortoise SVN, and Beyond Compare. It was a great combination for doing code reviews.

Now I use OSX and Git. I've managed to kludge together a bash script along with Gitx and DiffMerge to come up with a barely acceptable solution.

I've muddled along with this setup, and similar ones, for over a year. I've also tried using the Github diff viewer and the Gitx diff viewer, so it's not like I've not given them a chance.

There are so many smart people doing great stuff with Git. Why not the side-by-side diff with the option of seeing the entire file? With people who have used both, I've never heard of anyone that likes the single +/- view better, at least for more than a quick check.

Improve this question
4
  • You could setup TortoiseGit to use Beyond Compare for diiffs, in which case you would see the whole file side-by-side (however I never tested this setup personally [but plan to, one of these days]).
    – wildpeaks
    Commented Sep 22, 2011 at 12:56
  • 1
    Just a comment, I use to use the Windows, SVN and Beyond Compare. But, now I use Ubuntu + Git. Luckly, I can still use my old friend Beyond Compare. It works just fine on Ubuntu. And while not free, it's worth every penny to me. :) Sorry, I can't offer you a solution on OSX, but didn't want people to think that Beyond Compare was a Windows-only solution.
    – David S
    Commented Jun 21, 2012 at 0:31
  • 7 years later, I still feel this way somewhat, but I have trained myself to prefer the inline diff in all but the most complex cases. Then I break out my old friend Beyond Compare.
    – Kyle Heironimus
    Commented Sep 7, 2018 at 4:25
  • This works for me: "git difftool --dir-diff --tool=meld rev1 rev2" Meld allows keyboard navigation between changes, and --dir-diff allows me to go back and forth between files.
    – proski
    Commented Feb 6, 2020 at 0:22

4 Answers 4

Reset to default
18

I can't speak for Linus on this, but the way git handles difftools is very unixish, philosophically speaking. git does what it does very well, and uses external tools for everything else, including more sophisticated diffing and merging.

I use DiffMerge with git on OS X too, and I haven't had to resort to any bash shells. It was tricky, but I configured git's difftool and mergetool settings to call DiffMerge directly, and I can now view diffs and resolve merge conflicts in an excellent, visual third party tool.

Here's my config:

[mergetool "diffmerge"]
        cmd = "diffmerge --merge --result=\"$MERGED\" \"$LOCAL\" \"$(if test -f \"$BASE\"; then echo \"$BASE\"; else echo \"$LOCAL\"; fi)\" \"$REMOTE\""
        trustExitCode = false
[difftool "diffmerge"]
        cmd = diffmerge \"$LOCAL\" \"$REMOTE\"
[merge]
        tool = diffmerge
[diff]
        tool = diffmerge
Improve this answer
6
  • 1
    This does ok, but when several files change, I get to look at them one at a time, in the order that git decides to show them to me. I must close one to open another. That's why I also use bash scripts when I want to look at all the files at once.
    – Kyle Heironimus
    Commented Aug 24, 2011 at 22:08
  • I don't know what you'd be expecting to see in terms of "looking at them all at once". But check out git diff --stat. Gives you a nice graphical listing of all changed files, with the number of changed lines.
    – Dan Ray
    Commented Aug 25, 2011 at 13:27
  • Thinking a little more about this "open them all at once" thing... How many files can you edit/view at a time? I can only look at one file at any given moment. I guess I just don't get what you wish it would do.
    – Dan Ray
    Commented Aug 25, 2011 at 13:47
  • 3
    The best example is TortoiseSVN with Beyond Compare. For example, if my coworker's last commit has 3 files changed, it will show the three files in a list. I can then click on the appropriate file to see the differences. I could also have 3 separate windows open, each one with the different file. I can then go back and forth between them, as needed to examine the change. Basically, it allows you to view all the changes on your own terms, not serially in the order dictated by your vcs.
    – Kyle Heironimus
    Commented Aug 25, 2011 at 20:09
  • 1
    You know, you should check out Tower. It's the best Mac git gui I've ever seen, and does what you're talking about and WAY more. git-tower.com
    – Dan Ray
    Commented Aug 25, 2011 at 20:12
16

You'll notice that SVN itself doesn't offer a side-by-side solution, either. What you've listed are third-party tools. As with most things in git, this is extraordinarily configurable, and it has great tool support out of the box. Do you have a mergetool set up? If not, you should. If you do, try git difftool. Then have a look at the man page for config options.

I use KDiff3 as my mergetool since it's a nice, cross-platform tool, and with no further configuration, git difftool does exactly what you're asking.

Improve this answer
1
  • 2
    Actually, it does ok with difftool, but still fails when looking at lots of files. They must be opened one at a time. To open them all at once, I have to do bash script hackery.
    – Kyle Heironimus
    Commented Aug 24, 2011 at 22:10
9

It's the *nix philosophy. A lot of the people who use these tools spend a lot of time in the terminal. The terminal doesn't require us to move our hands from the keyboard to the mouse. I know that I prefer the +/- style to the visual diff/merge tools, mostly because I only care about the differences. I care about the 3-4 lines around the change and the change itself. Anything more is extra information that really doesn't help me.

Diff's are commonly used to get a quick look at what has been changed. Not to read the code.

I have never found the visual diff tools very useful compared to the default diff on GNU systems. All they ever make me do is start messing with the mouse and forcing me to scroll through the file, figure out their user interface, and then struggle on getting back into the command line where I can do something about a problem I see in the diff.

Improve this answer
3
  • 1
    vimdiff is okay, it usually only shows you the parts. I use it for merges; no mouse necessary.
    – alternative
    Commented Aug 24, 2011 at 14:55
  • 8
    Do you ever look at changes made by a coworker? To areas of the code you aren't as familiar with? I do all the time, and I cannot imagine doing it without side by side, all the code. For me, the +/- is great for changes made by be, but not for others. Not saying you are wrong or bad or anything. Just asking.
    – Kyle Heironimus
    Commented Aug 24, 2011 at 16:46
  • 1
    I often bounce into code changed by coworkers, often in areas I'm not familiar with. I think I've used side by side maybe 3 or 4 times ever, and could easily have done without. It just depends on what your preferred operating style is. It works for you, I find it unnecessary.
    – Brian Knoblauch
    Commented Sep 21, 2011 at 13:07
0

From my personal usage, I think the answer is mostly that diffs are short enough that it doesn't matter.

For code reviews, I use a full-featured code-review tool, that gives me all the things I like - like comments, syntax highlighting, and side-by-side view.

I use git diff almost exclusively during when staging code to commit; When that's the case, the diffs are small enough, and recent enough, that I don't need to see the context to remember what's going on.

My code-review tool of choice Phabricator, or possibly IDE-integrated tools, that are language context-aware. I think github's pull-request flow is terrible for code-review, mostly because it shows unified diff and not side-by-side.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.