Re: Question on textconv

On Tue, Aug 04, 2026 at 02:44:22PM -0400, [email protected] 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).

-Peff