Hi brian & Jack, On Fri, 20 Jan 2023, brian m. carlson wrote: > On 2023-01-19 at 18:06:17, Jack Adrian Zappa wrote: > > Here is the filled out form for submitting a bug report: > > > > What did you do before the bug happened? (Steps to reproduce your issue) > > > > At the command line, I typed the following command: > > > > $ git diff --no-index --word-diff --color=always <(od -An -t x1 > > -w10000000000 file1.txt) <(od -An -t x1 -w10000000000 file2.txt) > > > > What did you expect to happen? (Expected behavior) > > > > I expected to see the diff of the two files. > > > > What happened instead? (Actual behavior) > > > > Instead I saw this: > > > > error: Could not access '/proc/1961/fd/63' > > > > What's different between what you expected and what actually happened? > > > > The difference is that I would get the difference between the two > > files as opposed to a critical failure message. > > Thanks for the report. This has come up before (and I attempted a > patch), but the ultimate problem here is that the /proc/PID/fd/* files > are symlinks on Linux, and instead of dereferencing symlinks, Git tries > to read them and print where they point to. That doesn't work in this > case because the symlinks are symlinks to anonymous pipes, which can't > be resolved. > > On other systems, the behaviour may be different because those files may > be represented differently. > > My patch attempted to solve this by simply opening the contents instead > of stat'ing them as normal, but I think we found some edge cases and it > didn't get finished. Note that this behaviour is what plain diff does > because it doesn't handle symlinks at all. Please note that this is not about a bug in Git itself, but in the MSYS2 Bash that Git for Windows includes in its distribution. The technical details are quite involved, and I wrote up a ticket here, in case somebody is up for a real good challenge: https://github.com/git-for-windows/git/issues/4266 Ciao, Johannes
