Re: What's the idea of specifying binary=true together with textconv?

From: Jeff King <peff@peff.net>
Date: Sep 27, 2017, 19:18 UTC
Message-ID: <20170927191830.qegbaoxtcxzbfkoe@sigill.intra.peff.net>
In-Reply-To: <CAFU8umg2cgmmCvGYbu0P3M02AMcttUfTCFGTUcsF7shd80XwSw@mail.gmail.com>

On Wed, Sep 27, 2017 at 10:06:25PM +0300, Ilya Kantor wrote:

> When textconv is specified, the program is always used for conversion.

Not always. It's enabled by default for the git-diff and git-log" porcelain, but not for plumbing commands, nor for git-format-patch (which needs to create a patch that can be applied). And it can be disabled with --no-textconv.

Show 17 quoted lines

> E.g. consider this:
> [diff "png"]
>   textconv = wc
> 
> Even if a png file is ASCII (manually created), wc gets called, and
> the result is made of its output.
> 
> So, the question is: why should one specify binary = true together
> with textconv?
> 
> There is an example in docs:
> [diff "ps"]
>   textconv = ps2ascii
>   binary = true
> 
> ...But what binary = true does here?
> Even if we remove it, textconv is called for all ps-files.

Setting binary=true overrides Git's binary-detection heuristics. When textconv is in effect, those heuristics aren't used at all. But when it's disabled, if you want to make sure a file is marked as binary, it would kick in then. For example:

  $ git init
  $ echo fake-binary >foo.png
  $ echo "*.png diff=png" >.git/info/attributes
  $ git config diff.png.textconv "sed s/^/converted:/"
  $ git add .
  $ git commit -m foo

  $ git show
  ...
  --- /dev/null
  +++ b/foo.png
  @@ -0,0 +1 @@
  +converted:fake-binary

  $ git format-patch --stdout -1
  ...
  --- /dev/null
  +++ b/foo.png
  @@ -0,0 +1 @@
  +fake-binary

  $ git config diff.png.binary true
  $ git format-patch --stdout -1
  diff --git a/foo.png b/foo.png
  new file mode 100644
  index 0000000000000000000000000000000000000000..96060daf0866dbaf9538b76587f0da801bed4a5f
  GIT binary patch
  literal 12
  TcmYdG%udx!%FIhFs^kIy9YO?D
  
  literal 0
  HcmV?d00001

It's a pretty rare corner case where this is useful. After all, if your file really isn't binary, then a text patch is actually preferable. But you could imagine cases where the heuristics are wrong (e.g., a single NUL very far into the file).

-Peff