| Message ID | 20231020100343.GA2194322@coredump.intra.peff.net (mailing list archive) |
|---|---|
| Headers | show |
| Series | some send-email --compose fixes | expand |
Jeff King <peff@peff.net> writes: > [culling the rather large cc, as we moving off the original topic] > > On Fri, Oct 20, 2023 at 03:14:03AM -0400, Jeff King wrote: > >> and there's your perl array ref (from the square brackets, which are >> necessary because we're sticking it in a hash value). But even before >> your patch, this seems to end up as garbage. The code which reads >> $parsed_line does not dereference the array. >> >> The patch to fix it is only a few lines (well, more than that with some >> light editorializing in the comments): > > So here's the fix in a cleaned up form, guided by my own comments from > earlier. ;) I think this is actually all orthogonal to the patch you are > working on, so yours could either go on top or just be applied > separately. > > [1/3]: doc/send-email: mention handling of "reply-to" with --compose > [2/3]: Revert "send-email: extract email-parsing code into a subroutine" > [3/3]: send-email: handle to/cc/bcc from --compose message Nice. With the approach suggested to move the validation down to where the necessary addresses are already all defined, Michael observed "whoa, why am I getting stringified array ref?". If that is the only issue in the approach, queuing these three patches first and then have Michael's fix on top of them sounds like the cleanest thing to do. Will queue on top of v2.42.0 to help those who may want to backport these to the maintenance track. Thanks.
On Fri, Oct 20, 2023 at 02:42:13PM -0700, Junio C Hamano wrote: > > So here's the fix in a cleaned up form, guided by my own comments from > > earlier. ;) I think this is actually all orthogonal to the patch you are > > working on, so yours could either go on top or just be applied > > separately. > > > > [1/3]: doc/send-email: mention handling of "reply-to" with --compose > > [2/3]: Revert "send-email: extract email-parsing code into a subroutine" > > [3/3]: send-email: handle to/cc/bcc from --compose message > > Nice. > > With the approach suggested to move the validation down to where the > necessary addresses are already all defined, Michael observed "whoa, > why am I getting stringified array ref?". If that is the only issue > in the approach, queuing these three patches first and then have > Michael's fix on top of them sounds like the cleanest thing to do. I don't think it is even an issue in Michael's approach. I'd have to see his patch and how he tested it to be sure, but I suspect he was simply being extra careful to test nearby behavior and stumbled upon the ARRAY() bug. But the bug was there long before either of his patches. > Will queue on top of v2.42.0 to help those who may want to backport > these to the maintenance track. So I think you could take my series on top of master (or 2.42.0), and eventually target 'master'. The bug it fixes is from 2017, so not urgent. The reading of "to" headers is a new feature. But the fix to move the validation around should probably go directly onto a8022c5f7b (send-email: expose header information to git-send-email's sendemail-validate hook, 2023-04-19) for use on maint. I guess maybe it is not that urgent anymore, as that regression is in v2.41, and we would not release anything along that maint track anymore, though. -Peff
On 10/23/23 14:51, Jeff King wrote: > On Fri, Oct 20, 2023 at 02:42:13PM -0700, Junio C Hamano wrote: > >>> So here's the fix in a cleaned up form, guided by my own comments from >>> earlier. ;) I think this is actually all orthogonal to the patch you are >>> working on, so yours could either go on top or just be applied >>> separately. >>> >>> [1/3]: doc/send-email: mention handling of "reply-to" with --compose >>> [2/3]: Revert "send-email: extract email-parsing code into a subroutine" >>> [3/3]: send-email: handle to/cc/bcc from --compose message >> >> Nice. >> >> With the approach suggested to move the validation down to where the >> necessary addresses are already all defined, Michael observed "whoa, >> why am I getting stringified array ref?". If that is the only issue >> in the approach, queuing these three patches first and then have >> Michael's fix on top of them sounds like the cleanest thing to do. Patch coming soon. > > I don't think it is even an issue in Michael's approach. I'd have to see > his patch and how he tested it to be sure, but I suspect he was simply > being extra careful to test nearby behavior and stumbled upon the > ARRAY() bug. But the bug was there long before either of his patches. > Thank you for your patches Peff! I think it fixes the issue I was seeing. I was trying to be extra careful with my testing. I had missed testing --compose and also the multiple --to/cc/bcc examples before. >> Will queue on top of v2.42.0 to help those who may want to backport >> these to the maintenance track. > > So I think you could take my series on top of master (or 2.42.0), and > eventually target 'master'. The bug it fixes is from 2017, so not > urgent. The reading of "to" headers is a new feature. > > But the fix to move the validation around should probably go directly > onto a8022c5f7b (send-email: expose header information to > git-send-email's sendemail-validate hook, 2023-04-19) for use on maint. > I guess maybe it is not that urgent anymore, as that regression is in > v2.41, and we would not release anything along that maint track anymore, > though. > > -Peff