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

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 8, 2024, 21:57 UTC
Message-ID: <xmqqttfufzkj.fsf@gitster.g>
In-Reply-To: <20240808-jk-translate-alias-send-email-v1-3-10a03b3d6b06@gmail.com>

Jacob Keller <jacob.e.keller@intel.com> writes:

> From: Jacob Keller <jacob.keller@gmail.com>
>
> Add a new "--translate-aliases" option to git send-email which allows

If you add a thing, it by definition is new, isn't it?

> Instead, skip calling GetOptions a second time of --translate-aliases is

"of"???  "if" perhaps?

> set. This has the effect that known options will instead be translated
> as aliases instead of producing a warning, but this seems like the best
> trade off of the available options.

Hmph, I do not quite get why you need such a hack (to be honest, I do not quite understand why dump-aliases needs a similar hack, either, even though I do understand why identity thing needs a special caseing).

After GetOptions() returns, usuall we process everything remaining on the command line as files that contain messages, right? But before that happens (i.e. anywhere before the while () loop that processes elements in @ARGV), you can check if your new option was given, and if so you can map contents of @ARGV using %aliases and exit, and you are done, no? Bonus point if you make sure that no other options were given, but perhaps there are some strange folks who want to use "--to=fu" as an e-mail alias, so instead of complaining that "--translate" does not mix with any other options when "git send-email --translate --to=fu" was run, giving alias translation for "--to=fu" may be a better behaviour for those users anyway ;-).