Git development
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: rsbecker@nexbridge.com
Cc: git@vger.kernel.org
Subject: Re: Question on textconv
Date: Wed, 5 Aug 2026 00:50:26 -0400	[thread overview]
Message-ID: <20260805045026.GA972736@coredump.intra.peff.net> (raw)
In-Reply-To: <017e01dd2441$476839f0$d638add0$@nexbridge.com>

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).

-Peff

  parent reply	other threads:[~2026-08-05  4:50 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-04 18:44 Question on textconv rsbecker
2026-08-04 20:52 ` D. Ben Knoble
2026-08-04 21:45   ` rsbecker
2026-08-05  4:50 ` Jeff King [this message]
2026-08-05 11:36   ` D. Ben Knoble
2026-08-05 14:05   ` rsbecker
2026-08-06  4:10     ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260805045026.GA972736@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=rsbecker@nexbridge.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox