Re: [PATCH 3/3] send-email: teach git send-email option to translate aliases

[Jacob Keller <jacob.e.keller@intel.com>]

On 8/9/2024 2:05 PM, Junio C Hamano wrote:
> Jacob Keller <jacob.e.keller@intel.com> writes:
> 
>> We could try to implement scanning for options ourselves, but I wouldn't
>> want to break things like "--" to make it treat potential option-looking
>> fields as aliases...
> 
> The appoach --dump-aliases takes is already broken with respect to
> options that take or do not take an argument, if you really want to
> scan, understand, and skip irrelevant options anyway, no?  The
> separate, trimmed down %dump_aliases_options map cannot help you to
> tell from the command line "git cmd --translate --foo bar" if
> skipping just "--foo" gives you the alias-to-be-expanded "bar", or
> "--foo" takes an argument that is "bar" and there is no alias left.
> 

The approach --dump-aliases takes is that *any* other command line
argument besides --dump-aliases will cause git send-email to exit with
an error. They are not interpreted.

The approach I had --translate-aliases take is that all other command
line arguments are treated as aliases, regardless of whether they are
possibly options, and no other options are parsed at all.

It is intended that --dump-aliases, --translate-aliases, and the regular
mode of operation are mutually exclusive.

I am leaning towards possibly making --translate-aliases take the
aliases to translate on stdin instead of using arguments at all. This
would make it function more like --dump-aliases w.r.t. command line
arguments. This is probably a lot simpler. I think I will implement it
this way for v2.

Alternatively, we could extract the logic for handling the aliases into
a separate script with its own git command, but I think it currently
relies heavily on some perl code that would be hard to translate to C.