Eh, (2)/(3) can be a pain for web mail accounts. For instance, I couldn't send patches to LKML through Gmail directly, since even for plain-text emails it wants to rewrap long lines itself. To get "git send-email" working through it, I had to wade through a bunch of outdated info to find the right method.
Even now there are persistent downsides: every email through "git send-email" contains my original IP address for everyone to see, unless I use a VPN service. Also, since I'm not a right-thinking person with a 'real' client-based inbox, I have to fiddle with the In-Reply-To and References headers by hand, if I want to include a patch in a reply to another email.
> every email through "git send-email" contains my original IP address for everyone to see
Is this the fault of git or your SMTP provider? I looked through a mailman archive and couldn't find my client IP address. The first Received headers refer to my email host.
The final Received header has "Received: from <my local hostname> (<my ISP's hostname for my IP address> [<my IP address>]) by smtp.gmail.com with ESMTPSA id <blah blah blah>". Regardless of who's to blame, it makes it more of a pain to send any raw email through SMTP, using "git send-email" or otherwise.
Even now there are persistent downsides: every email through "git send-email" contains my original IP address for everyone to see, unless I use a VPN service. Also, since I'm not a right-thinking person with a 'real' client-based inbox, I have to fiddle with the In-Reply-To and References headers by hand, if I want to include a patch in a reply to another email.