0

git difftool seems to get confused on Windows. If a new file has been added, Git sends "\.\nul" as the 'left' file to the diff tool.

To reproduce this:

{create a new file}
git add .
git difftool --staged

Now, WinMerge (or whichever viewer you're using) starts but reports that the left path ("\.\nul") is invalid.

This problem has been reported over the years several times on SO. For example, this is the exact same issue:

How to get winmerge to show diff for new file in git?

However, the accepted solution in the above question (and all the others) simply doesn't work for me. And now that we're in 2020, is there an official workaround for this problem?

Mercurial has never had this problem. It sends the diff viewer valid paths and works perfectly. I'm surprised to run into this issue with Git.

Tom B
  • 115
  • 8

1 Answers1

1

Git needs to provide a way to indicate that a particular file doesn't exist. This happens when a file is created or deleted.

On Unix, the typical way to indicate a file component that doesn't exist in a diff is to specify /dev/null. However, Windows doesn't specify its devices within a particular path; instead, the NUL device is accessible from any path where the file name is NUL.

Despite what WinMerge tells you, this is indeed a valid path, and it should work just fine in Windows. (For example, you should be able to write something like git diff --no-index \.\nul foo.c, where foo.c is a path in your project, at a CMD or PowerShell prompt.) If you're seeing this issue, perhaps you should report it to the WinMerge issue tracker.

bk2204
  • 64,793
  • 6
  • 84
  • 100
  • Hmm, this doesn't appear to be specific to WinMerge. This issue occurs with all three of the diff programs I've tried on Windows: WinMerge, DiffMerge, and KDiff3. And Mercurial never had this issue with the very same programs. – Tom B Mar 10 '20 at 23:07
  • If you think it's a bug in Git for Windows, you can report it there, which it [looks like you already have](https://github.com/git-for-windows/git/issues/2543). I'm pretty sure that is indeed a valid path on Windows, though, but I don't have a Windows box to test. – bk2204 Mar 11 '20 at 22:43