On Sat, Mar 26, 2016 at 7:43 AM, 惠轶群 <huiyiqun@xxxxxxxxx> wrote: > 2016-03-26 2:16 GMT+08:00 Junio C Hamano <gitster@xxxxxxxxx>: >> 惠轶群 <huiyiqun@xxxxxxxxx> writes: >> >>> # Purpose >>> The current implementation of send-email is based on perl and has only >>> a tui, it has two problems: >>> - user must install a ton of dependencies before submit a single patch. >>> - tui and parameter are both not quite friendly to new users. >> >> Is "a ton of dependencies" true? "apt-cache show git-email" >> suggests otherwise. Is "a ton of dependencies" truly a problem? >> "apt-get install" would resolve the dependencies for you. > > There are three perl packages needed to send patch through gmail: > - perl-mime-tools > - perl-net-smtp-ssl > - perl-authen-sasl > > Yes, not too many, but is it better none of them? Are you sure using a GUI does not have any dependencies? > What's more, when I try to send mails, I was first disrupted by > "no perl-mime-tools" then by "no perl-net-smtp-ssl or perl-authen-sasl". > Then I think, why not just a mailto link? > >>> # Plan >>> So I propose to implement following: >>> - Allow user to send mail via a [`mailto` >>> link](https://en.wikipedia.org/wiki/Mailto). so that users could >>> complete the mail in their favorite email clients such as gmail, mutt, >>> alpine and even gmail for android through >> >> IIRC, GMail on Android is incapable of sending a "text/plain", so >> that part may not fly well. > > Really? As much as I known, GMail on Android is capable of sending > a "text/plain" while Inbox is not. How do you plan in integrating GMail on Android so that it can send patches which exists on your computer? >>> - Build a simple email client (maybe a web components based web app or >>> wxwidgets based GUI client, they are both cross-platform) which is >>> easy to use for sending patch without disrupting the mailbox format. I think introducing a GUI may lead to much more dependencies. Many git developers already have perl packages in their system but they don't have wxwidgets. >> I suspect it would yield a better result if the plan were to update >> a popular email client and make it possible to tell it to read an >> existing text file (i.e. mbox) without corrupting its contents. >> People do not have to learn a new mail client if done that way. > > Maybe a plugin? I'm not sure. You could make a plugin. That would simply things. > If above `mail-to` is implemented, user could just using any mail > client, but a mail client adaptive for patch would be better: > - Do not allow user to edit the diff part > - always 'plan/text' > - visual -- 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