Matthieu Moy writes
> To me, the answer should be: do whatever the RFC says in email headers.
> I'd expect anything that works in the To: header to work in the --to
> option of git send-email.
Ok sounds good to me !
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body
Remi Lespinet writes:
> Ok, but I don't know what fixed means in these particular cases.
> Actually the problem when we have a quote in a name is: Is this a
> delimiter or is this an ascii char?
To me, the answer should be: do whatever the RFC says in email headers.
I'd expect anything that work
Matthieu Moy writes
> I would say that using parse_address_line is good for consistancy in Git
> anyway. If the behavior of parse_address_line is broken on some
> corner-cases, then it should be fixed anyway.
Ok, but I don't know what fixed means in these particular cases.
Actually the proble
Remi Lespinet writes:
> Currently, git send-email contains a function which splits at commas
> with respect to quotes (parse_address_line introduced by
> 5012699d9840fe34fe0838ea0d529c2f32f76b82).
It seems I had missed this one, but indeed, it should probably be used
instead of split_at_commas i
Hi,
I'm currently working on git send-email to allow passing names
containing commas. I would like to specify that the comma
shouldn't be interpreted as a delimiter when there's quotes
around:
"Jane, Katarina Doe"
This changes the behavior of the double quote. For example
when passing:
--t
5 matches
Mail list logo
