Reputation: 135
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.
Upvotes: 0
Views: 304
Reputation: 76924
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.
Upvotes: 1