Re: Giving command line parameter to textconv command?

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 15, 2009, 05:56 UTC
Message-ID: <7vfx7c3hmb.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20091215121110.6117@nanako3.lavabit.com>

Nanako Shiraishi <nanako3@lavabit.com> 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.