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

From: Jacob Keller <jacob.e.keller@intel.com>
Date: Aug 9, 2024, 19:51 UTC
Message-ID: <5ad39a07-a2d4-45d2-9b5d-0180cb903801@intel.com>
In-Reply-To: <xmqq7ccpcx9e.fsf@gitster.g>

On 8/9/2024 12:27 PM, Junio C Hamano wrote:

Show 9 quoted lines

> Jacob Keller <jacob.e.keller@intel.com> writes:
> 
>> Dump aliases handled this by checking @ARGV and immediately bailing if
>> there were anything remaining after the call to parsing its inner
>> options. This works but does not work for --translate-aliases because it
>> needs to treat all the remaining arguments as aliases.
> 
> When GetOptions returns, shouldn't these "remaining arguments" be
> visible in @ARGV and you can iterate over them yourself, perhaps?

Yes, that is essentially what we do by skipping the call to the GetOptions for the main set of send-email options :)

We still need to go farther down the program in order to call the functions which parse the alias file and setup the alias map.

I guess we could re-arrange the code so that the alias bits are handled before the options?

We also probably want to reject other option-like arguments which ideally we would have GetOpt::Long handle for us... I think if we disable pass_through initially in the identity/information options and then re-enable it when we call the second GetOptions that might work? That could get tricky...

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

Or we could completely change the overall behavior to do something else like take the aliases on standard input instead of the arguments?