{"thread":{"id":"64374","subject":"Handling of improperly-configured custom diff drivers is confusing","startedAt":"2025-10-23T23:29:53Z","lastAt":"2025-10-23T23:29:53Z","messageCount":1,"participants":["Gesh"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"529538","messageId":"ok3e53h6kxxv4ukvwe4e6bac24ph5oykffrc26fqmwkrltm25e@byvhfqgfygsv","threadId":"64374","inReplyTo":null,"subject":"Handling of improperly-configured custom diff drivers is confusing","fromName":"Gesh","fromEmail":"gesh@gesh.uni.cx","sentAt":"2025-10-23T23:29:47Z","receivedAt":"2025-10-23T23:29:53Z","isPatch":false,"sender":{"key":"gesh@gesh.uni.cx","avatar":null},"body":"Hi,\nAfter investigating what I thought was a git bug, I ultimately found it was due\nto my misconfiguring the diff.pdf driver. In particular, I had (years ago now)\nmisread either the git docs or the pdftotext manual, because I had naively\nconfigured\ndiff.pdf.textconv = pdftotext\nUnfortunately, pdftotext's default behaviour is to write the text to a new file,\nnot stdout -- the correct configuration is\ndiff.pdf.textconv = sh -c 'pdftotext \"$0\" -'\nAll this is well and good, and thankfully this episode has left me with a better\nconfiguration. Although, it would perhaps be nice to have git warn on a textconv\nconfiguration that was constantly emitting an empty file for existent files.\n\nMoreover, my investigation yielded some surprising (and underdocumented?)\ninformation:\n- It appears that triggering a textconv driver with cachetextconv set generates\n  a commit. I caught this because I configure the user information per-repo, so\n  diff was complaining the user wasn't configured\n- Custom diff drivers are run in a temp directory subsequently rmdir'd by git.\n  In particular, they _can_ write to disk, but must cleanup after themselves.\n  Caught this because my configuration *was* leaving files around -- but git\n  only complained it couldn't rmdir.\n- git diff and git log crash if in the course of printing a custom diff driver\n  crashes. In particular, they cut off printing. This was useful, because it\n  meant I actually bumped into this bug, instead of it slipping my notice as I\n  jumped in the output to the tag I was interested in.\n- git log --simplify-by-decoration seems to generate some sort of squash commit\n  of all the commits between two nodes it prints, but display them under the\n  existing SHA. I think this was the first time I used simplify-by-decoration\n  this thoroughly, so I hadn't noticed this before.\n\nNot sure how much of this is actionable -- it ultimately ended up being my\nfault, but I'd've appreciated clearer diagnostic messages and clarifications in\nthe docs.\n\nEither way, hope this is useful to someone.\nGesh\n"}]}