Nanako Shiraishi <nanako3@xxxxxxxxxxx> writes: > I experimented with other variables (eg. smudge and clean) and > they honor their command line arguments. If textconv is the only > setting that doesn't, the change may be easier to justify. Yes, as you found out, convert.c::apply_filter() is aware of the command line arguments. Let's try to do a bit more work to make the coverage complete. After scanning "git grep -e start_async -e run_command" output, here is what I came up with: - editor.c::launch_editor() that allows a custom editor named via GIT_EDITOR does seem to honor your command line arguments. - pager.c::setup_pager() is used for GIT_PAGER and it does honor your command line arguments. - ll-merge.c::ll_ext_merge() that is used to handle custom merge drivers lets the user specify command line via templating to replace %O %A %B and naturally it needs to be aware of the command line arguments. - diff.c::run_external_diff() that runs GIT_EXTERNAL_DIFF defines that the command has to take 7 parameters in a fixed order, and is not designed to permute its arguments like ll_ext_merge() does, but these days people don't use it directly (they use it indirectly via "difftool" wrapper), so it probably is not an issue. - merge-index.c::merge_entry() also defines a strict order and semantics to its parameters, but similar to GIT_EXTERNAL_DIFF, it is not something you would throw a ready-made program (like an editor or an pager) and expect it to work, so it wouldn't be an issue either. Hooks do not even take arbitrary command line arguments, so we don't have to worry about them. So it does look like that textconv is the only odd-man out. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html