Junio C Hamano <gitster@xxxxxxxxx> writes: > The reason why we have the "verify the input" thing, allow users to > supply multiple --to/--cc/etc., and do not try to split the > addresses ourselves is because we want to avoid mistakenly splitting > a single address like the above into two and producing syntactically > incorrect addresses. People have relied on the current behaviour > for a long time, without manually dropping comma when they send > their patches with --to='"Jane, Doe" <jdoe@xxxxxxxxxxx>'. Yes, but they couldn't send with --to='"Jane, Doe" <jdoe@xxxxxxxxxxx>' anyway since 79ee555b (Check and document the options to prevent mistakes. 2006-06-21). So I don't think that this part is a regression. However when the user input is incorrect and contains comma, the mail will be sent to the syntaxically valid addresses which have been extracted and this would have failed without sending before this patch. I agree that this part is not a desirable behavior. If I fix that, would it be ok for you? 2015-06-01 18:52 GMT+02:00 Junio C Hamano <gitster@xxxxxxxxx>: > Junio C Hamano <gitster@xxxxxxxxx> writes: > >> Remi Lespinet <remi.lespinet@xxxxxxxxxxxxxxxxxxxxxxx> writes: >> >>> Accept a list of emails separated by commas in flags --cc, --to and >>> --bcc. Multiple addresses can already be given by using these options >>> multiple times, but it is more convenient to allow cutting-and-pasting >>> a list of addresses from the header of an existing e-mail message, >>> which already lists them as comma-separated list, as a value to a >>> single parameter. >>> >>> The following format can now be used: >>> >>> $ git send-email --to='Jane <jdoe@xxxxxxxxxxx>, mike@xxxxxxxxxxx' >>> >>> However format using commas in names doesn't work: >>> >>> $ git send-email --to='"Jane, Doe" <jdoe@xxxxxxxxxxx>' >> >> That looks as if you are doing "Remi, Lespinet", which is not a good >> example. I think you want "Doe, Jane", the use of comma is when a >> name is spelled in the "LastName, FirstName" order. > > Having thought about this topic (not how the example should be > spelled in the log message ;-) a bit more, I do not think the > implementation of split_address_list_items in this patch is > acceptable. > > The reason why we have the "verify the input" thing, allow users to > supply multiple --to/--cc/etc., and do not try to split the > addresses ourselves is because we want to avoid mistakenly splitting > a single address like the above into two and producing syntactically > incorrect addresses. People have relied on the current behaviour > for a long time, without manually dropping comma when they send > their patches with --to='"Jane, Doe" <jdoe@xxxxxxxxxxx>'. > > Until we can reliably split the address list, accepting this patch > will introduce a regression. > > Note that I do agree with the goal of this series and appreciate the > effort. I am only rejecting the current implementation of > split_address_list_items(). > > Thanks. > > > > > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html