When I do `git difftool -d @^^`, I get a left & right directory. My understanding is that the left directory represents 2 commits worth of diffs and the right one represents my "working copy". In my case, my difftool is beyond compare 4 on Windows. In that difftool, I have symlinks enabled. I also prefer this to avoid copies when doing large diffs. When I move changes to *existing* files from left to right, in other words I'm modifying a file already in my working copy, those changes are persisted when I close my difftool. This is working as expected. However, let's say in my tip commit, I deleted a file. But since I'm diffing further back, I can attempt to restore that deleted file to my working copy by moving it from left to right. From Beyond Compare's perspective, this particular file exists on the left, but not the right side. My expectation is that when a new file is created on the right, that that file appears in my working copy when I close the diff tool. However, that is not the case. The file appears to be moved over during the diff, but the result is not retained. The file is still missing in my working copy and any changes I made to it in beyond compare are seemingly lost. I imagine this is working by design. It makes sense that git only watches for changes *to existing files* in the temp directories. It probably just ignores any files that were not originally on the right side to begin with. My ask here is to see if there is any way to get this to work as I expect. It's convenient to be able to restore deleted files inside difftool, so I'm wondering if this is possible somehow.
