RE: Question on textconv

[<rsbecker@nexbridge.com>]

On August 5, 2026 12:50 AM, Jeff King wrote:
> 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).

Could we extend textconv to support %f (the original path) if specified in the
textconv configuration? That would solve the ambiguity of what is being supplied.