On Mon, Dec 05, 2016 at 11:56:31AM +0100, Johannes Schindelin wrote: > Hi Peter, > > On Mon, 5 Dec 2016, P. Duijst wrote: > > > On 12/5/2016 06:15, David Aguilar wrote: > > > On Fri, Dec 02, 2016 at 05:05:06PM +0100, Johannes Schindelin wrote: > > > > > > > > On Fri, 2 Dec 2016, P. Duijst wrote: > > > > > > > > > Incase filenames are used with a quote ' or a bracket [ (and > > > > > maybe some more characters), git "diff" and "difftool -y" works > > > > > fine, but git *difftool **-d* gives the next error message: > > > > > > > > > > peter@scm_ws_10 MINGW64 /d/Dev/test (master) > > > > > $ git diff > > > > > diff --git a/Test ''inch.txt b/Test ''inch.txt > > > > > index dbff793..41f3257 100644 > > > > > --- a/Test ''inch.txt > > > > > +++ b/Test ''inch.txt > > > > > @@ -1 +1,3 @@ > > > > > + > > > > > +ddd > > > > > Test error in simple repository > > > > > warning: LF will be replaced by CRLF in Test ''inch.txt. > > > > > The file will have its original line endings in your working > > > > > directory. > > > > > > > > > > peter@scm_ws_10 MINGW64 /d/Dev/test (master) > > > > > *$ git difftool -d* > > > > > *fatal: Cannot open '/d/Dev/test//Test ''inch.txt': No such file or > > > > > directory* > > > > > *hash-object /d/Dev/test//Test ''inch.txt: command returned error: > > > > > 128* > > > > > > > > > > peter@scm_ws_10 MINGW64 /d/Dev/test (master) > > > > > $ > > > > > > > > > > > > > > > This issue is inside V2.10.x and V2.11.0. > > > > > V2.9.0 is working correctly... > > > > You say v2.11.0, but did you also try the new, experimental builtin > > > > difftool? You can test without reinstalling: > > > > > > > > git -c difftool.useBuiltin=true difftool -d ... > > > > > > FWIW, I verified that this problem does not manifest itself on Linux, > > > using the current scripted difftool. > > > > > > Peter, what actual diff tool are you using? > > > > > > Since these filenames work fine with "difftool -d" on Linux, it > > > suggests that this is either a tool-specific issue, or an issue > > > related to unix-to-windows path translation. > > > > @Johannes: "git -c difftool.useBuiltin=true difftool -d" works OK :-), beyond > > compare is launching with the diff's displayed > > Perfect. > > In that case, I think it is not worth fixing the scripted tool but focus > on getting rid of it in favor of the builtin version. > > It's not like it is the only problem with having difftool implemented > as a script... I just sent some patches[1] that makes it so that difftool always operates from the top-level of the repo, particularly when calling hash-object. They also eliminate using paths with embedded "//" in them, both of which may have caused this issue Though we can side-step this specific issue with the new builtin difftool, if our use of hash-object with double-slashed absolute paths was not the problem reported above, then another possibility is that there's a problem in the Git.pm Perl module, which affects more than just difftool. I'm curious to understand the root cause of the problem. Does Git.pm go through a shell on Windows? Why was hash-object complaining about the correct path, but reported that it didn't exist? Did having "//" in the path cause the problem? Enlightenment from the GFW internals perspective is much appreciated. Since this reportedly worked in older versions, I'm led to believe that 32b8c581ec (difftool: use Git::* functions instead of passing around state), which first introduced the use of paths with embedded "//", was the root cause. If this is true then the patches should fix the scripted difftool on Windows. [1] http://public-inbox.org/git/20161209085848.10929-1-davvid@xxxxxxxxx/T/#t cheers, -- David