>
> I experienced a change in how textconv works since about 2.50 and it is hard
> to get past. I would appreciate advice:
>
> When I define an external binary textconv, roughly like:
>
> .gitattributes:
> simple binary diff=enscr
>
> .gitconfig
> [diff "enscr"]
>         textconv = run -debug ../../enscribe-conv --verbose
>         binary = true
>
> The supplied file going to the textconv program looks like
> /tmp/git-blob-GFtIhK/simple
> and is always empty regardless of the file contents.

> When there is only one file named simple in the repository I can find it,
> but otherwise
> any ambiguity in the name makes textconv processing impractical. Somewhere
> prior to this
> I was supplied with the actual file in the working index instead of a temp
> file.
>
> Am I missing something?
>
> Thanks,
> Randall

> On Tue, Aug 4, 2026 at 2:52 PM <rsbecker@nexbridge.com> wrote:
> >
> > I experienced a change in how textconv works since about 2.50 and it
> > is hard to get past. I would appreciate advice:
> >
> > When I define an external binary textconv, roughly like:
> >
> > .gitattributes:
> > simple binary diff=enscr
> >
> > .gitconfig
> > [diff "enscr"]
> >         textconv = run -debug ../../enscribe-conv --verbose
> >         binary = true
> >
> > The supplied file going to the textconv program looks like
> > /tmp/git-blob-GFtIhK/simple and is always empty regardless of the file
> > contents.
> 
> That's strange. Over here (2.53.0), I get the temp file, but it has the expected
> contents.
> 
> (For example, I can debug a bit by using the shell form 'textconv =
> "f() { echo $@; cat $@; <stuff>; }; f"'. NB those $@ need quoted in production, but
> for my little test case that was more hassle than it was worth. We can also see the
> invocation using GIT_TRACE2=1.)
> 
> This was true for me even after setting "binary = true" in the diff driver block, which
> I thought was a bit unusual.
> 
> > When there is only one file named simple in the repository I can find
> > it, but otherwise any ambiguity in the name makes textconv processing
> > impractical. Somewhere prior to this I was supplied with the actual
> > file in the working index instead of a temp file.
> >
> > Am I missing something?
> >
> > Thanks,
> > Randall
> 
> I'm not sure :/

>
> On Tue, Aug 04, 2026 at 02:44:22PM -0400, rsbecker@nexbridge.com wrote:
>
> > The supplied file going to the textconv program looks like
> > /tmp/git-blob-GFtIhK/simple
> > and is always empty regardless of the file contents.
>
> I can't reproduce the problem here, even for files with embedded NULs.

> On Tue, Aug 04, 2026 at 02:44:22PM -0400, rsbecker@nexbridge.com wrote:
> 
> > The supplied file going to the textconv program looks like
> > /tmp/git-blob-GFtIhK/simple and is always empty regardless of the file
> > contents.
> 
> I can't reproduce the problem here, even for files with embedded NULs.
> However...
> 
> > When there is only one file named simple in the repository I can find
> > it, but otherwise any ambiguity in the name makes textconv processing
> > impractical. Somewhere prior to this I was supplied with the actual
> > file in the working index instead of a temp file.
> 
> This part I can explain. We sometimes try to reuse the working tree instead of
> generating a tempfile, as an optimization. We can only do this when the working
> tree file is clean. But we also only bother to try when one of the diff endpoints is
> the index. So if we set up a sample textconv like:
> 
>   git config diff.foo.textconv 'echo >&2 "got: $*" && tr a-z A-Z <'
>   echo "file diff=foo" >.gitattributes
> 
>   echo one >file && git add file && git commit -m one
>   echo two >file && git add file && git commit -m two
> 
> The running either "git diff HEAD^" or "git diff --cached HEAD^" will convert the
> copy in the working tree, and you'll get:
> 
>   got: /tmp/git-blob-0CLCMr/file
>   got: file
>   diff --git a/file b/file
>   index 5626abf..f719efd 100644
>   --- a/file
>   +++ b/file
>   @@ -1 +1 @@
>   -ONE
>   +TWO
> 
> but if you do "git show HEAD", you'll get two tempfiles:
> 
>   got: /tmp/git-blob-w1binM/file
>   got: /tmp/git-blob-1nu2Rm/file
>   [same diff]
> 
> even though this is the same diff! We _could_ try harder to reuse the working tree
> copy here by checking whether the path has the same sha1 in the tree and the
> index (and that the index entry is clean). But it only helps in a few special cases, and
> it's not something users should rely on (we might choose to create a tempfile
> anyway if the index is stat-dirty).