All of lore.kernel.org
 help / color / mirror / Atom feed
From: <rsbecker@nexbridge.com>
To: "'D. Ben Knoble'" <ben.knoble@gmail.com>
Cc: <git@vger.kernel.org>
Subject: RE: Question on textconv
Date: Tue, 4 Aug 2026 17:45:13 -0400	[thread overview]
Message-ID: <01ac01dd245a$8b64f990$a22eecb0$@nexbridge.com> (raw)
In-Reply-To: <CALnO6CD+LmWNffptqp4bsoJQaq7Ah8VaKHjTTu6m-Zfm2uN+9w@mail.gmail.com>

On August 4, 2026 4:53 PM, D. Ben Knoble wrote:
> 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 :/

Curiously, I get this only on binary files. It is almost as if leading nulls is causing an issue.
If I try on a text file or an ELF format file, the above works - ELF does not begin with a NULL.


  reply	other threads:[~2026-08-04 21:45 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 [this message]
2026-08-05  4:50 ` Jeff King
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='01ac01dd245a$8b64f990$a22eecb0$@nexbridge.com' \
    --to=rsbecker@nexbridge.com \
    --cc=ben.knoble@gmail.com \
    --cc=git@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.