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

From: Jacob Keller <jacob.e.keller@intel.com>
Date: Aug 10, 2024, 00:29 UTC
Message-ID: <7f6d556c-c1fe-4a6f-be6f-106f2e0bca48@intel.com>
In-Reply-To: <xmqqplqhbe4o.fsf@gitster.g>

On 8/9/2024 2:05 PM, Junio C Hamano wrote:

Show 14 quoted lines

> 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.