* b4 send suggestion: handle .git_aliases @ 2023-12-12 17:27 Vlastimil Babka 2023-12-12 19:41 ` Konstantin Ryabitsev 2023-12-15 19:20 ` Kernel.org Bugbot 0 siblings, 2 replies; 5+ messages in thread From: Vlastimil Babka @ 2023-12-12 17:27 UTC (permalink / raw) To: tools Hi, It would be nice if b4 send --to/cc used .git_aliases and also if something malformed is given to it (such as an alias it doesn't handle now), warn instead of just dropping it silently. Thanks! Vlastimil ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: b4 send suggestion: handle .git_aliases 2023-12-12 17:27 b4 send suggestion: handle .git_aliases Vlastimil Babka @ 2023-12-12 19:41 ` Konstantin Ryabitsev 2023-12-14 12:33 ` Vlastimil Babka 2023-12-15 19:20 ` Kernel.org Bugbot 1 sibling, 1 reply; 5+ messages in thread From: Konstantin Ryabitsev @ 2023-12-12 19:41 UTC (permalink / raw) To: Vlastimil Babka; +Cc: tools On Tue, Dec 12, 2023 at 06:27:50PM +0100, Vlastimil Babka wrote: > It would be nice if b4 send --to/cc used .git_aliases I recall looking at that before, but it's non-trivial. There are 6 different formats the aliases file can be in: sendemail.aliasesFile To avoid typing long email addresses, point this to one or more email aliases files. You must also supply sendemail.aliasFileType. sendemail.aliasFileType Format of the file(s) specified in sendemail.aliasesFile. Must be one of mutt, mailrc, pine, elm, gnus, or sendmail. There is git-send-email --dump-aliases, but, unhelpfully, it will only dump the shortnames, not the destinations. I don't have a good solution in my head right now other than creating fake patches, passing them to git-send-email with -to on the CLI and then parsing what we get out of it. Which is horrible, but is about just as horrible as creating a parser for 6 different file formats. > and also if something malformed is given to it (such as an alias it doesn't > handle now), warn instead of just dropping it silently. That part at least I can handle properly. -K ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: b4 send suggestion: handle .git_aliases 2023-12-12 19:41 ` Konstantin Ryabitsev @ 2023-12-14 12:33 ` Vlastimil Babka 2023-12-15 19:17 ` Konstantin Ryabitsev 0 siblings, 1 reply; 5+ messages in thread From: Vlastimil Babka @ 2023-12-14 12:33 UTC (permalink / raw) To: Konstantin Ryabitsev; +Cc: tools On 12/12/23 20:41, Konstantin Ryabitsev wrote: > On Tue, Dec 12, 2023 at 06:27:50PM +0100, Vlastimil Babka wrote: >> It would be nice if b4 send --to/cc used .git_aliases > > I recall looking at that before, but it's non-trivial. There are 6 different > formats the aliases file can be in: > > sendemail.aliasesFile > To avoid typing long email addresses, point this to one or more email aliases files. You must > also supply sendemail.aliasFileType. > > sendemail.aliasFileType > Format of the file(s) specified in sendemail.aliasesFile. Must be one of mutt, mailrc, pine, > elm, gnus, or sendmail. > > There is git-send-email --dump-aliases, but, unhelpfully, it will only dump > the shortnames, not the destinations. That's unhelpful to the point I wonder why the option was even implemented :) > I don't have a good solution in my head right now other than creating fake > patches, passing them to git-send-email with -to on the CLI and then parsing > what we get out of it. Which is horrible, but is about just as horrible as > creating a parser for 6 different file formats. Understood. >> and also if something malformed is given to it (such as an alias it doesn't >> handle now), warn instead of just dropping it silently. > > That part at least I can handle properly. Aha, and also just noticed that given multiple --cc parameters b4 only takes the last one and not add them up (--to probably the same). Although --help documents it as such, it seems an unnecessary gotcha for somebody used to git send-email. Thanks, Vlastimil > -K ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: b4 send suggestion: handle .git_aliases 2023-12-14 12:33 ` Vlastimil Babka @ 2023-12-15 19:17 ` Konstantin Ryabitsev 0 siblings, 0 replies; 5+ messages in thread From: Konstantin Ryabitsev @ 2023-12-15 19:17 UTC (permalink / raw) To: Vlastimil Babka; +Cc: tools On Thu, Dec 14, 2023 at 01:33:22PM +0100, Vlastimil Babka wrote: > >> and also if something malformed is given to it (such as an alias it doesn't > >> handle now), warn instead of just dropping it silently. > > > > That part at least I can handle properly. > > Aha, and also just noticed that given multiple --cc parameters b4 only > takes the last one and not add them up (--to probably the same). > Although --help documents it as such, it seems an unnecessary gotcha for > somebody used to git send-email. Recording this for myself. bugbot on ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: b4 send suggestion: handle .git_aliases 2023-12-12 17:27 b4 send suggestion: handle .git_aliases Vlastimil Babka 2023-12-12 19:41 ` Konstantin Ryabitsev @ 2023-12-15 19:20 ` Kernel.org Bugbot 1 sibling, 0 replies; 5+ messages in thread From: Kernel.org Bugbot @ 2023-12-15 19:20 UTC (permalink / raw) To: vbabka, tools Hello: This conversation is now tracked by Kernel.org Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=218272 There is no need to do anything else, just keep talking. -- Deet-doot-dot, I am a bot. Kernel.org Bugzilla (peebz 0.1) ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-12-15 19:20 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-12-12 17:27 b4 send suggestion: handle .git_aliases Vlastimil Babka 2023-12-12 19:41 ` Konstantin Ryabitsev 2023-12-14 12:33 ` Vlastimil Babka 2023-12-15 19:17 ` Konstantin Ryabitsev 2023-12-15 19:20 ` Kernel.org Bugbot
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.