git difftool --dir-diff Not Working with BC4 on OS X

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • segfault
    Visitor
    • Aug 2014
    • 4

    git difftool --dir-diff Not Working with BC4 on OS X

    I am using Beyond Compare 4.0 beta (build 18746) on Mac OS X 10.9.4 with Git 2.1.0.

    I have configured Git to use bcomp as shown here.

    When BC opens, both sides of the directory structure are shown, but BC doesn't properly compare the files. It creates two entries for each file (one for each side), so that both sides show alternating rows of filenames and empty space (file names on one side always appear across from empty space on the other side.) In other words, all files appear as orphans, even though they aren't orphans. The files on the right appear to be treated like symlinks, while the files on the left do not.

    Double clicking an empty row on the left (or a file in the same row on the right) causes BC to display the path to the file that appears on the right. Double clicking a file on the left (or the empty space in the same row on the right) causes BC to show a diff for the file that shows its contents being removed (all content appears on the left side of the file diff, no content appears on the right.)

    This seems completely broken. Does BC4 support git --dir-diff?

    And one more unrelated question, is it possible for BC4 to automatically expand a folder structure when it first opens? This functionality seems to have appeared in earlier versions of BC but I don't see an equivalent setting in 4.0.

    Thanks!
  • nikolaus
    Expert
    • Apr 2013
    • 71

    #2
    Session Settings > Handling > Follow Symbolic Links. Instead of "Use for this view only" at the bottom, select "Also update session defaults".

    Comment

    • Aaron
      Team Scooter
      • Oct 2007
      • 16000

      #3
      Hello,

      Sorry, I haven't had time to setup this scenario yet. Do all of the items have little arrow icons on one or both sides? This would indicate they are symbolic links, and we don't follow them by default. Following nikolaus' suggestion would instead follow them to their target and allow the comparison. A full screen screenshot would help show the scenario you are hitting.
      Aaron P Scooter Software

      Comment

      • segfault
        Visitor
        • Aug 2014
        • 4

        #4
        Originally posted by nikolaus
        Session Settings > Handling > Follow Symbolic Links. Instead of "Use for this view only" at the bottom, select "Also update session defaults".
        That did the trick, thanks!

        Originally posted by Aaron
        Hello,

        Sorry, I haven't had time to setup this scenario yet. Do all of the items have little arrow icons on one or both sides? This would indicate they are symbolic links, and we don't follow them by default. Following nikolaus' suggestion would instead follow them to their target and allow the comparison. A full screen screenshot would help show the scenario you are hitting.
        The arrows (symlinks) only showed up on the right side, but since they weren't being followed by default, every file was showing up as orphaned on both sides. Since the implementation "git difftool --dir-diff" uses symlinks, the fact that BC4 doesn't follow symlinks by default is what threw me off.

        Comment

        • mikelehen
          New User
          • Sep 2014
          • 1

          #5
          That worked for me too, but I only found it after I gave up on BC4, tried several other diff tools over the course of a few weeks, and then finally gave BC4 one last chance and finally landed on this thread with the solution. Given that the failure mode is pretty hard to diagnose (I had no idea the issue was with symlinks; I just knew dir-diff wasn't working at all) and git uses symlinks by default, it might be a good idea to either change the default settings to make this work out-of-the-box, or at least provide a useful error ("WARNING: symlinks were encountered and were ignored. Go to blah blah to change your settings.").

          Comment

          • AndrewCarter
            Visitor
            • Sep 2013
            • 5

            #6
            Bump. I experienced the same issue and had to find this thread for the solution. Would likely be better to have the follow symlinks option default to true.

            Another option is to pass --no-symlinks switch to git difftool command

            Comment

            Working...