git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: GIT_TRACE doesn't show content filter files it's operating on

From
Jeff King <peff@peff.net>
Date
Aug 27, 2018, 23:53 UTC
Message-ID
<20180827235321.GB11663@sigill.intra.peff.net>
In-Reply-To
<3fdc0c24-bbee-e7b3-ec43-7e926cee71e1@stason.org>
On Mon, Aug 27, 2018 at 04:23:34PM -0700, Stas Bekman wrote:
Show 20 quoted lines
> I'm debugging the workings of a configured git content filter
> (nbstripout) and I'm trying to get GIT_TRACE to show me the files it's
> operating on, but it doesn't. Consider:
> 
> $ GIT_TRACE=1 git pull origin master
> [...] removed irrelevant sections of the output
> 16:49:28.846707 run-command.c:640       trace: run_command: git merge
> FETCH_HEAD
> 16:49:28.849309 git.c:344               trace: built-in: git merge
> FETCH_HEAD
> Updating 1ea49ad..ae0ba93
> 16:49:28.863291 run-command.c:640       trace: run_command: nbstripout
> 16:49:28.864700 run-command.c:640       trace: run_command: nbstripout
> 16:49:28.866060 run-command.c:640       trace: run_command: nbstripout
> [...] many more of the same
> 
> How can I get GIT_TRACE's run_command to show the arguments passed to
> the filter? I looked at various other debug environment variables in
> git's manual, but I don't see anything that would enable that level of
> debug.

GIT_TRACE should always show the arguments. But unless you specify arguments in the clean/smudge filter config, then Git won't pass any. The stdin/stdout stream is all that matters.

So e.g.:
  $ echo '* filter=foo' >.gitattributes
  $ git config filter.foo.clean 'myfilter'
  $ GIT_TRACE=1 git add .
  19:42:16.516401 [pid=14112] git.c:415             trace: built-in: git add .
  19:42:16.517454 [pid=14112] run-command.c:637     trace: run_command: myfilter
  $ git config filter.foo.clean 'myfilter --foo'
  $ touch .gitattributes ;# make sure we actually read it again ;)
  $ GIT_TRACE=1 git add .
  19:42:58.122942 [pid=14156] git.c:415             trace: built-in: git add .
  19:42:58.124023 [pid=14156] run-command.c:637     trace: run_command: 'myfilter --foo'
You can use "%f" to pass the name of the file, like:
  $ git config filter.foo.clean 'myfilter %f'
  $ touch .gitattributes
  $ GIT_TRACE=1 git add .
  19:44:51.187177 [pid=14318] git.c:415             trace: built-in: git add .
  19:44:51.188256 [pid=14318] run-command.c:637     trace: run_command: 'myfilter '\''.gitattributes'\'''

Of course that won't be helpful if your filter actually respects the argument. For a "clean" filter that might be OK (e.g., if it just tells your filter to read from the filesystem instead of stdin), but it's almost certainly not what you want for a "smudge" filter.

You can work around it with some shell hackery:
  git config filter.foo.clean 'f() { echo >&2 "cleaning $1"; myfilter ...; }; f %f'
and then even without GIT_TRACE, you get:
  $ git add .
  cleaning .gitattributes
Or if you really just want to trigger for GIT_TRACE, try just this:
  $ git config filter.foo.clean 'f() { myfilter; }; f %f'
  19:52:52.874064 [pid=14719] git.c:415             trace: built-in: git add .
  19:52:52.875115 [pid=14719] run-command.c:637     trace: run_command: 'f() { myfilter; }; f '\''.gitattributes'\'''

There you get the name in the trace output, but the invoked command doesn't actually do anything with it.

-Peff
Previous: Stas BekmanNext: Stas Bekman
Message 2 of 6 in “GIT_TRACE doesn't show content filter files it's operating on”
  1. Stas BekmanAug 27, 2018
  2. Jeff KingAug 27, 2018
  3. Stas BekmanAug 28, 2018
  4. Jeff KingAug 28, 2018
  5. Stas BekmanAug 28, 2018
  6. Stas BekmanAug 28, 2018

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.