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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jacob Keller <jacob.e.keller@xxxxxxxxx> writes:

> From: Jacob Keller <jacob.keller@xxxxxxxxx>
>
> 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 ;-).





[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux