Symlink issues with git difftool

[voidpointer]

Using `git difftool -d @^`, to diff my working copy against the previous revision with symlink support enabled in session settings, if I copy over *new* files (files deleted in the latest revision) they do not appear in my working copy. If I modify existing files, those changes do get carried over. Is this a git issue or a BC one?

[Aaron]

Hello,

I think I've set up this scenario (a previous n-1 commit with an additional file that was deleted, compared to a newer local that is missing the file), and I think this is a Git issue. Both sides are temp managed directories (even the 'current' local one), and any changes to the files within it are pushed up to the real local files, but any newly copied files are not, despite being in the Git managed temp version of the local/current folder.

This might be due to my simpler test environment, but I didn't need to use the BC4 option to Follow Symbolic links, or the Git --no-symlinks, when working with a local repository. Both sides were real file listings of git generated temp directories.

[voidpointer]

File paths show up weird in BC4 if you don't have symlinks enabled. Been a while since I've had it off, but I know it definitely felt broken/weird without it on.

[Aaron]

Hello,

You can also tell git to avoid using symlinks with the --no-symlinks git option. By "file paths" do you mean the base folder paths at the top? Or the subfolder content of the diff itself? The paths do look 'weird' since Git is generating two temp directories and putting copies of the content you want to compare into them, then passing those directories to BC4. It then detects when BC4 is closed and uses the temp dirs to update the appropriate real locations (but not Adds, it seems).

Side note: BC4 itself also has a /vcsleft and /vcsright or /title1 /title2 parameter sets to override the displayed path content with a more human-readable title, but last I looked git doesn't have a variable to pass on the command line to express that.

[voidpointer]

By weird I mean that BC4 didn't recognize the ancestry between the two directories. There technically wasn't one, but logically there is. That's why the symlinks make it look better, in my opinion.

Disabling symlinks at the git-level would result in a lot of file copies which will make it really slow for big diffs. I prefer the symlinks.

Again thank you for all the help. I may start a discussion on the git mailing list to see if this is something that needs support in Git.

[Aaron]

If they have any feedback, we'd be interested in knowing what it is. You can post here or email us at [email protected] (along with a link back to this forum thread for our reference) if they know of something we should be doing instead.