{"thread":{"id":"41827","subject":"[GSoC] A late proposal: a modern send-email","startedAt":"2016-03-25T17:59:08Z","lastAt":"2016-04-05T00:03:06Z","messageCount":15,"participants":["惠轶群","Junio C Hamano","Pranit Bauva","Eric Wong","Javier Domingo Cansino","Ævar Arnfjörð Bjarmason","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"281842","messageId":"CAKqreuyC8p9m_dgVpXCiT_hf=8qBA_5kZ5NABQGx0QDOiCBbww@mail.gmail.com","threadId":"41827","inReplyTo":null,"subject":"[GSoC] A late proposal: a modern send-email","fromName":"惠轶群","fromEmail":"huiyiqun@gmail.com","sentAt":"2016-03-25T17:59:08Z","receivedAt":"2016-03-25T17:59:08Z","isPatch":false,"sender":{"key":"huiyiqun@gmail.com","avatar":"https://gravatar.com/avatar/44aa01fbc2fb098682386b82a44aac03bd778275249228c55d09c5b6fe2fe0e0?d=mp&s=160"},"body":"I know it's tooo late to post proposal here, but I'd like to let my\nidea known by\nothers.\n\n# Summary\nAlthough many projects hosted on github or gitlab adopt the\nfork-and-merge working flow, email is still irreplaceable for its\ncompatibility. However, the send-email module is old and difficult for\nnew users. I’d like to improve it and implement a more modern\ninterface for git-send-email.\n\n# Purpose\nThe current implementation of send-email is based on perl and has only\na tui, it has two problems:\n- user must install a ton of dependencies before submit a single patch.\n- tui and parameter are both not quite friendly to new users.\n\n# Plan\nSo I propose to implement following:\n- Allow user to send mail via a [`mailto`\nlink](https://en.wikipedia.org/wiki/Mailto). so that users could\ncomplete the mail in their favorite email clients such as gmail, mutt,\nalpine and even gmail for android through\n[termux](https://termux.com/) (termux is a terminal emulator on\nAndroid and has an API to call android system to open a link).\n- Build a simple email client (maybe a web components based web app or\nwxwidgets based GUI client, they are both cross-platform) which is\neasy to use for sending patch without disrupting the mailbox format.\n\nHere is my proposal:\n\nhttps://docs.google.com/document/d/1PbaKJOUWjpAh0JEunqhKWiWW4SAr_-7DH_ss4WkgDGs/edit\n"},{"id":"281852","messageId":"xmqqzitm2zkj.fsf@gitster.mtv.corp.google.com","threadId":"41827","inReplyTo":"CAKqreuyC8p9m_dgVpXCiT_hf=8qBA_5kZ5NABQGx0QDOiCBbww@mail.gmail.com","subject":"Re: [GSoC] A late proposal: a modern send-email","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-03-25T18:16:12Z","receivedAt":"2016-03-25T18:16:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"惠轶群 writes:\n\n> # Purpose\n> The current implementation of send-email is based on perl and has only\n> a tui, it has two problems:\n> - user must install a ton of dependencies before submit a single patch.\n> - tui and parameter are both not quite friendly to new users.\n\nIs \"a ton of dependencies\" true? \"apt-cache show git-email\"\nsuggests otherwise. Is \"a ton of dependencies\" truly a problem?\n\"apt-get install\" would resolve the dependencies for you.\n\n> # Plan\n> So I propose to implement following:\n> - Allow user to send mail via a [`mailto`\n> link](https://en.wikipedia.org/wiki/Mailto). so that users could\n> complete the mail in their favorite email clients such as gmail, mutt,\n> alpine and even gmail for android through\n\nIIRC, GMail on Android is incapable of sending a \"text/plain\", so\nthat part may not fly well.\n\n> - Build a simple email client (maybe a web components based web app or\n> wxwidgets based GUI client, they are both cross-platform) which is\n> easy to use for sending patch without disrupting the mailbox format.\n\nI suspect it would yield a better result if the plan were to update\na popular email client and make it possible to tell it to read an\nexisting text file (i.e. mbox) without corrupting its contents.\nPeople do not have to learn a new mail client if done that way.\n\nThat may not be a \"Git\" project, but GSoC is not limited to Git ;-)\n"},{"id":"281898","messageId":"CAKqreux1S2ioEEjPPCkyz1NJnXJ1RyiWdM5thZD607PkL0HKuQ@mail.gmail.com","threadId":"41827","inReplyTo":"xmqqzitm2zkj.fsf@gitster.mtv.corp.google.com","subject":"Re: [GSoC] A late proposal: a modern send-email","fromName":"惠轶群","fromEmail":"huiyiqun@gmail.com","sentAt":"2016-03-26T02:13:47Z","receivedAt":"2016-03-26T02:13:47Z","isPatch":false,"sender":{"key":"huiyiqun@gmail.com","avatar":"https://gravatar.com/avatar/44aa01fbc2fb098682386b82a44aac03bd778275249228c55d09c5b6fe2fe0e0?d=mp&s=160"},"body":"2016-03-26 2:16 GMT+08:00 Junio C Hamano :\n> 惠轶群 writes:\n>\n>> # Purpose\n>> The current implementation of send-email is based on perl and has only\n>> a tui, it has two problems:\n>> - user must install a ton of dependencies before submit a single patch.\n>> - tui and parameter are both not quite friendly to new users.\n>\n> Is \"a ton of dependencies\" true? \"apt-cache show git-email\"\n> suggests otherwise. Is \"a ton of dependencies\" truly a problem?\n> \"apt-get install\" would resolve the dependencies for you.\n\nThere are three perl packages needed to send patch through gmail:\n- perl-mime-tools\n- perl-net-smtp-ssl\n- perl-authen-sasl\n\nYes, not too many, but is it better none of them?\n\nWhat's more, when I try to send mails, I was first disrupted by\n\"no perl-mime-tools\" then by \"no perl-net-smtp-ssl or perl-authen-sasl\".\nThen I think, why not just a mailto link?\n\n>> # Plan\n>> So I propose to implement following:\n>> - Allow user to send mail via a [`mailto`\n>> link](https://en.wikipedia.org/wiki/Mailto). so that users could\n>> complete the mail in their favorite email clients such as gmail, mutt,\n>> alpine and even gmail for android through\n>\n> IIRC, GMail on Android is incapable of sending a \"text/plain\", so\n> that part may not fly well.\n\nReally? As much as I known, GMail on Android is capable of sending\na \"text/plain\" while Inbox is not.\n\n>> - Build a simple email client (maybe a web components based web app or\n>> wxwidgets based GUI client, they are both cross-platform) which is\n>> easy to use for sending patch without disrupting the mailbox format.\n>\n> I suspect it would yield a better result if the plan were to update\n> a popular email client and make it possible to tell it to read an\n> existing text file (i.e. mbox) without corrupting its contents.\n> People do not have to learn a new mail client if done that way.\n\nMaybe a plugin? I'm not sure.\n\nIf above `mail-to` is implemented, user could just using any mail\nclient, but a mail client adaptive for patch would be better:\n- Do not allow user to edit the diff part\n- always 'plan/text'\n- visual\n\n> That may not be a \"Git\" project, but GSoC is not limited to Git ;-)\n\nSorry, but I do not really mean to implement a general mail client.\nIn fact, this is a GUI front end for git send-mail and may be placed\nunder contrib/\n"},{"id":"281900","messageId":"CAFZEwPOa3i9XTF-5ZWZXvXfAzpyFojz57JBy4_WahF0Y4Q9DWQ@mail.gmail.com","threadId":"41827","inReplyTo":"CAKqreux1S2ioEEjPPCkyz1NJnXJ1RyiWdM5thZD607PkL0HKuQ@mail.gmail.com","subject":"Re: [GSoC] A late proposal: a modern send-email","fromName":"Pranit Bauva","fromEmail":"pranit.bauva@gmail.com","sentAt":"2016-03-26T06:18:27Z","receivedAt":"2016-03-26T06:18:27Z","isPatch":false,"sender":{"key":"pranit.bauva@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2959938?v=4"},"body":"On Sat, Mar 26, 2016 at 7:43 AM, 惠轶群 wrote:\n> 2016-03-26 2:16 GMT+08:00 Junio C Hamano :\n>> 惠轶群 writes:\n>>\n>>> # Purpose\n>>> The current implementation of send-email is based on perl and has only\n>>> a tui, it has two problems:\n>>> - user must install a ton of dependencies before submit a single patch.\n>>> - tui and parameter are both not quite friendly to new users.\n>>\n>> Is \"a ton of dependencies\" true? \"apt-cache show git-email\"\n>> suggests otherwise. Is \"a ton of dependencies\" truly a problem?\n>> \"apt-get install\" would resolve the dependencies for you.\n>\n> There are three perl packages needed to send patch through gmail:\n> - perl-mime-tools\n> - perl-net-smtp-ssl\n> - perl-authen-sasl\n>\n> Yes, not too many, but is it better none of them?\n\nAre you sure using a GUI does not have any dependencies?\n\n> What's more, when I try to send mails, I was first disrupted by\n> \"no perl-mime-tools\" then by \"no perl-net-smtp-ssl or perl-authen-sasl\".\n> Then I think, why not just a mailto link?\n>\n>>> # Plan\n>>> So I propose to implement following:\n>>> - Allow user to send mail via a [`mailto`\n>>> link](https://en.wikipedia.org/wiki/Mailto). so that users could\n>>> complete the mail in their favorite email clients such as gmail, mutt,\n>>> alpine and even gmail for android through\n>>\n>> IIRC, GMail on Android is incapable of sending a \"text/plain\", so\n>> that part may not fly well.\n>\n> Really? As much as I known, GMail on Android is capable of sending\n> a \"text/plain\" while Inbox is not.\n\nHow do you plan in integrating GMail on Android so that it can send\npatches which exists on your computer?\n\n>>> - Build a simple email client (maybe a web components based web app or\n>>> wxwidgets based GUI client, they are both cross-platform) which is\n>>> easy to use for sending patch without disrupting the mailbox format.\n\nI think introducing a GUI may lead to much more dependencies. Many git\ndevelopers already have perl packages in their system but they don't\nhave wxwidgets.\n\n>> I suspect it would yield a better result if the plan were to update\n>> a popular email client and make it possible to tell it to read an\n>> existing text file (i.e. mbox) without corrupting its contents.\n>> People do not have to learn a new mail client if done that way.\n>\n> Maybe a plugin? I'm not sure.\n\nYou could make a plugin. That would simply things.\n\n> If above `mail-to` is implemented, user could just using any mail\n> client, but a mail client adaptive for patch would be better:\n> - Do not allow user to edit the diff part\n> - always 'plan/text'\n> - visual\n"},{"id":"281903","messageId":"CAKqreuyN--AjjhTcTx1+Baec=j-6TJPj8Rwoxre86TJp2UMGDg@mail.gmail.com","threadId":"41827","inReplyTo":"CAFZEwPOa3i9XTF-5ZWZXvXfAzpyFojz57JBy4_WahF0Y4Q9DWQ@mail.gmail.com","subject":"Re: [GSoC] A late proposal: a modern send-email","fromName":"惠轶群","fromEmail":"huiyiqun@gmail.com","sentAt":"2016-03-26T09:52:29Z","receivedAt":"2016-03-26T09:52:29Z","isPatch":false,"sender":{"key":"huiyiqun@gmail.com","avatar":"https://gravatar.com/avatar/44aa01fbc2fb098682386b82a44aac03bd778275249228c55d09c5b6fe2fe0e0?d=mp&s=160"},"body":"2016-03-26 14:18 GMT+08:00 Pranit Bauva :\n> On Sat, Mar 26, 2016 at 7:43 AM, 惠轶群 wrote:\n>> 2016-03-26 2:16 GMT+08:00 Junio C Hamano :\n>>> 惠轶群 writes:\n>>>\n>>>> # Purpose\n>>>> The current implementation of send-email is based on perl and has only\n>>>> a tui, it has two problems:\n>>>> - user must install a ton of dependencies before submit a single patch.\n>>>> - tui and parameter are both not quite friendly to new users.\n>>>\n>>> Is \"a ton of dependencies\" true? \"apt-cache show git-email\"\n>>> suggests otherwise. Is \"a ton of dependencies\" truly a problem?\n>>> \"apt-get install\" would resolve the dependencies for you.\n>>\n>> There are three perl packages needed to send patch through gmail:\n>> - perl-mime-tools\n>> - perl-net-smtp-ssl\n>> - perl-authen-sasl\n>>\n>> Yes, not too many, but is it better none of them?\n>\n> Are you sure using a GUI does not have any dependencies?\n>\n>> What's more, when I try to send mails, I was first disrupted by\n>> \"no perl-mime-tools\" then by \"no perl-net-smtp-ssl or perl-authen-sasl\".\n>> Then I think, why not just a mailto link?\n>>\n>>>> # Plan\n>>>> So I propose to implement following:\n>>>> - Allow user to send mail via a [`mailto`\n>>>> link](https://en.wikipedia.org/wiki/Mailto). so that users could\n>>>> complete the mail in their favorite email clients such as gmail, mutt,\n>>>> alpine and even gmail for android through\n>>>\n>>> IIRC, GMail on Android is incapable of sending a \"text/plain\", so\n>>> that part may not fly well.\n>>\n>> Really? As much as I known, GMail on Android is capable of sending\n>> a \"text/plain\" while Inbox is not.\n>\n> How do you plan in integrating GMail on Android so that it can send\n> patches which exists on your computer?\n\nNo, if you could have termux a try, you will find that it's suitable for simple\ndevelopment. it has a apt, so you could have clang, neovim, tmux, cmake\nand so on.\n\nIn fact, I recently use my nexus 7 with termux as a portable\ndevelopment environment.\nA bluetooth keyboard is needed, of course.\n\n>>>> - Build a simple email client (maybe a web components based web app or\n>>>> wxwidgets based GUI client, they are both cross-platform) which is\n>>>> easy to use for sending patch without disrupting the mailbox format.\n>\n> I think introducing a GUI may lead to much more dependencies. Many git\n> developers already have perl packages in their system but they don't\n> have wxwidgets.\n\nwxwidgets seems not a good choice. But if I build the GUI via web app,\nI could import required js and css from Internet directly, so the users do\nnot need the dependencies on their computer.\n\n>>> I suspect it would yield a better result if the plan were to update\n>>> a popular email client and make it possible to tell it to read an\n>>> existing text file (i.e. mbox) without corrupting its contents.\n>>> People do not have to learn a new mail client if done that way.\n>>\n>> Maybe a plugin? I'm not sure.\n>\n> You could make a plugin. That would simply things.\n>\n>> If above `mail-to` is implemented, user could just using any mail\n>> client, but a mail client adaptive for patch would be better:\n>> - Do not allow user to edit the diff part\n>> - always 'plan/text'\n>> - visual\n"},{"id":"281904","messageId":"CAKqreuyb1D7_D9iGWAqnLFc9ERsmEM-nu0LWdg1P4u7+aV6zGQ@mail.gmail.com","threadId":"41827","inReplyTo":"CAKqreuyN--AjjhTcTx1+Baec=j-6TJPj8Rwoxre86TJp2UMGDg@mail.gmail.com","subject":"Re: [GSoC] A late proposal: a modern send-email","fromName":"惠轶群","fromEmail":"huiyiqun@gmail.com","sentAt":"2016-03-26T10:18:55Z","receivedAt":"2016-03-26T10:18:55Z","isPatch":false,"sender":{"key":"huiyiqun@gmail.com","avatar":"https://gravatar.com/avatar/44aa01fbc2fb098682386b82a44aac03bd778275249228c55d09c5b6fe2fe0e0?d=mp&s=160"},"body":"To make it clearer:\n\n1. there are so many great mail clients, why not let these experts to handle the\n dispatch of mail?\n\nFor example, as a One-time-password user of gmail, I have to generate an app\npassword for each terminal device I'd like to send patch on.\n\nIt's more important that I could not use my favorite mail client which\nhas contact\nlist, familiar interface and more personal configuration.\n\nWhy not let one program just do one thing and do it best?\n\nIn my opinion, `mailto` is a suitable method. git is one of the best\nversion control\nsystems. So it forms basic structure of the mail according to the\npatches and passes it\nto the best mail client. How amazing.\n\n2. But this workload is not enough for whole summer. I thought I could do other\n interesting things based on the `mailto` link.\n\nmail client is a straightforward choice.\n\nIn fact, I meant to implement an interface more friendly to new users.\nno matter how\nit is implemented or what it is based on. The first time I send patch\nvia gmail is not a\nhappy memory.\n"},{"id":"281905","messageId":"CAKqreuz-0DMPgZKKthSQk0oBwL=6GiiT9wj2SMPS--fiwfpwGw@mail.gmail.com","threadId":"41827","inReplyTo":"CAKqreuyN--AjjhTcTx1+Baec=j-6TJPj8Rwoxre86TJp2UMGDg@mail.gmail.com","subject":"Re: [GSoC] A late proposal: a modern send-email","fromName":"惠轶群","fromEmail":"huiyiqun@gmail.com","sentAt":"2016-03-26T10:21:29Z","receivedAt":"2016-03-26T10:21:29Z","isPatch":false,"sender":{"key":"huiyiqun@gmail.com","avatar":"https://gravatar.com/avatar/44aa01fbc2fb098682386b82a44aac03bd778275249228c55d09c5b6fe2fe0e0?d=mp&s=160"},"body":"2016-03-26 17:52 GMT+08:00 惠轶群 :\n> 2016-03-26 14:18 GMT+08:00 Pranit Bauva :\n>> On Sat, Mar 26, 2016 at 7:43 AM, 惠轶群 wrote:\n>>> 2016-03-26 2:16 GMT+08:00 Junio C Hamano :\n>>>> 惠轶群 writes:\n>>>>\n>>>>> # Purpose\n>>>>> The current implementation of send-email is based on perl and has only\n>>>>> a tui, it has two problems:\n>>>>> - user must install a ton of dependencies before submit a single patch.\n>>>>> - tui and parameter are both not quite friendly to new users.\n>>>>\n>>>> Is \"a ton of dependencies\" true? \"apt-cache show git-email\"\n>>>> suggests otherwise. Is \"a ton of dependencies\" truly a problem?\n>>>> \"apt-get install\" would resolve the dependencies for you.\n>>>\n>>> There are three perl packages needed to send patch through gmail:\n>>> - perl-mime-tools\n>>> - perl-net-smtp-ssl\n>>> - perl-authen-sasl\n>>>\n>>> Yes, not too many, but is it better none of them?\n>>\n>> Are you sure using a GUI does not have any dependencies?\n>>\n>>> What's more, when I try to send mails, I was first disrupted by\n>>> \"no perl-mime-tools\" then by \"no perl-net-smtp-ssl or perl-authen-sasl\".\n>>> Then I think, why not just a mailto link?\n>>>\n>>>>> # Plan\n>>>>> So I propose to implement following:\n>>>>> - Allow user to send mail via a [`mailto`\n>>>>> link](https://en.wikipedia.org/wiki/Mailto). so that users could\n>>>>> complete the mail in their favorite email clients such as gmail, mutt,\n>>>>> alpine and even gmail for android through\n>>>>\n>>>> IIRC, GMail on Android is incapable of sending a \"text/plain\", so\n>>>> that part may not fly well.\n>>>\n>>> Really? As much as I known, GMail on Android is capable of sending\n>>> a \"text/plain\" while Inbox is not.\n>>\n>> How do you plan in integrating GMail on Android so that it can send\n>> patches which exists on your computer?\n>\n> No, if you could have termux a try, you will find that it's suitable for simple\n> development. it has a apt, so you could have clang, neovim, tmux, cmake\n> and so on.\n>\n> In fact, I recently use my nexus 7 with termux as a portable\n> development environment.\n> A bluetooth keyboard is needed, of course.\n\nThis is not applicable to all people, but It make the git more free, isn't it?\n\n>>>>> - Build a simple email client (maybe a web components based web app or\n>>>>> wxwidgets based GUI client, they are both cross-platform) which is\n>>>>> easy to use for sending patch without disrupting the mailbox format.\n>>\n>> I think introducing a GUI may lead to much more dependencies. Many git\n>> developers already have perl packages in their system but they don't\n>> have wxwidgets.\n>\n> wxwidgets seems not a good choice. But if I build the GUI via web app,\n> I could import required js and css from Internet directly, so the users do\n> not need the dependencies on their computer.\n>\n>>>> I suspect it would yield a better result if the plan were to update\n>>>> a popular email client and make it possible to tell it to read an\n>>>> existing text file (i.e. mbox) without corrupting its contents.\n>>>> People do not have to learn a new mail client if done that way.\n>>>\n>>> Maybe a plugin? I'm not sure.\n>>\n>> You could make a plugin. That would simply things.\n>>\n>>> If above `mail-to` is implemented, user could just using any mail\n>>> client, but a mail client adaptive for patch would be better:\n>>> - Do not allow user to edit the diff part\n>>> - always 'plan/text'\n>>> - visual\n"},{"id":"281947","messageId":"20160327220002.GA29057@dcvr.yhbt.net","threadId":"41827","inReplyTo":"xmqqzitm2zkj.fsf@gitster.mtv.corp.google.com","subject":"Re: [GSoC] A late proposal: a modern send-email","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2016-03-27T22:00:02Z","receivedAt":"2016-03-27T22:00:02Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Junio C Hamano wrote:\n> 惠轶群 writes:\n> > - Build a simple email client (maybe a web components based web app or\n> > wxwidgets based GUI client, they are both cross-platform) which is\n> > easy to use for sending patch without disrupting the mailbox format.\n> \n> I suspect it would yield a better result if the plan were to update\n> a popular email client and make it possible to tell it to read an\n> existing text file (i.e. mbox) without corrupting its contents.\n> People do not have to learn a new mail client if done that way.\n\nAnother bigger problem is people rely heavily on webmail UIs\nnowadays instead of running any local mail clients :<\n\nWhile Gmail provides SMTP access, it was (last I was told)\nincompatible with two-factor auth; so I've encountered users\nunable to send patches with their normal 2FA-enabled accounts.\n\nMaybe git hackers at Google have enough pull to lobby Gmail's\nweb interface to make it easier to send plain-text patches;\nbut I would love more to see users running local mail clients\nand even running their own SMTP servers.\n\n> That may not be a \"Git\" project, but GSoC is not limited to Git ;-)\n\nCompletely agreed; email is critical to decentralized development;\nbut I don't believe decentralization is in the best interests of\nany large and powerful corporation.\n\nIMHO, what we need is a SoIS: Summer of Independent Sysadmins :>\n"},{"id":"281948","messageId":"CALZVapn9KjXCpO+zaYuB6RSnG747u4a7e_m_HDg+uH-uz8UhQg@mail.gmail.com","threadId":"41827","inReplyTo":"20160327220002.GA29057@dcvr.yhbt.net","subject":"Re: [GSoC] A late proposal: a modern send-email","fromName":"Javier Domingo Cansino","fromEmail":"javierdo1@gmail.com","sentAt":"2016-03-27T23:31:27Z","receivedAt":"2016-03-27T23:31:27Z","isPatch":false,"sender":{"key":"javierdo1@gmail.com","avatar":"https://gravatar.com/avatar/0f43d4d2e5f4320e8b5e1a46914213c5459dd0de261ab1587f222827f863d727?d=mp&s=160"},"body":"> While Gmail provides SMTP access, it was (last I was told)\n> incompatible with two-factor auth; so I've encountered users\n> unable to send patches with their normal 2FA-enabled accounts.\n>\n> Maybe git hackers at Google have enough pull to lobby Gmail's\n> web interface to make it easier to send plain-text patches;\n> but I would love more to see users running local mail clients\n> and even running their own SMTP servers.\n\nJust in case, I use git send email with my gmail account and I have 2\nstep auth configured. The only \"limitation\" however is that you have\nto create a password for each email client on it's own. If you own a\ngmail account, go to\nhttps://security.google.com/settings/security/apppasswords to create a\npassword for the email client.\n\n-- \nJavier Domingo Cansino\n"},{"id":"281954","messageId":"CAKqreuzE6G0WO4gn2_R7-QfZYfVS2tuAMEnwiVE8FyNviJGD+Q@mail.gmail.com","threadId":"41827","inReplyTo":"20160327220002.GA29057@dcvr.yhbt.net","subject":"Re: [GSoC] A late proposal: a modern send-email","fromName":"惠轶群","fromEmail":"huiyiqun@gmail.com","sentAt":"2016-03-28T13:00:04Z","receivedAt":"2016-03-28T13:00:04Z","isPatch":false,"sender":{"key":"huiyiqun@gmail.com","avatar":"https://gravatar.com/avatar/44aa01fbc2fb098682386b82a44aac03bd778275249228c55d09c5b6fe2fe0e0?d=mp&s=160"},"body":"2016-03-28 6:00 GMT+08:00 Eric Wong :\n> Junio C Hamano wrote:\n>> 惠轶群 writes:\n>> > - Build a simple email client (maybe a web components based web app or\n>> > wxwidgets based GUI client, they are both cross-platform) which is\n>> > easy to use for sending patch without disrupting the mailbox format.\n>>\n>> I suspect it would yield a better result if the plan were to update\n>> a popular email client and make it possible to tell it to read an\n>> existing text file (i.e. mbox) without corrupting its contents.\n>> People do not have to learn a new mail client if done that way.\n>\n> Another bigger problem is people rely heavily on webmail UIs\n> nowadays instead of running any local mail clients :<\n\nI know many heavily email user choose to migrate to client such as\nalpine or mutt after using gmail for a long time.\n\n> While Gmail provides SMTP access, it was (last I was told)\n> incompatible with two-factor auth; so I've encountered users\n> unable to send patches with their normal 2FA-enabled accounts.\n\nThat's the origin of this idea of `mailto`.\n\nIn fact, you could send mail via 2FA-enabled accounts via\n\"app password\" metioned by Javier. But it's annoying to create\n\"app password\" for every client.\n\nIf there is a `mailto` method to send patch, you could type something\nlike\n\n git send-patch --mailto origin/master..HEAD\n\nThen, gmail is launched with the content of patch in it. You could edit\nthe list of `to` and `cc`(You could even take use of gmail contact). Then\njust send. That's all. No need to SMTP config or \"app password\" any\nmore.\n\n> Maybe git hackers at Google have enough pull to lobby Gmail's\n> web interface to make it easier to send plain-text patches;\n> but I would love more to see users running local mail clients\n> and even running their own SMTP servers.\n\nYes, this should be free with user to pick their favorite mail client.\n\n>> That may not be a \"Git\" project, but GSoC is not limited to Git ;-)\n>\n> Completely agreed; email is critical to decentralized development;\n> but I don't believe decentralization is in the best interests of\n> any large and powerful corporation.\n>\n> IMHO, what we need is a SoIS: Summer of Independent Sysadmins :>\n"},{"id":"281969","messageId":"CACBZZX6q87dw6UW9z+2bAvvWu0WZcYCMD8gxW8MchHwd8Rv3kw@mail.gmail.com","threadId":"41827","inReplyTo":"CAKqreux1S2ioEEjPPCkyz1NJnXJ1RyiWdM5thZD607PkL0HKuQ@mail.gmail.com","subject":"Re: [GSoC] A late proposal: a modern send-email","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2016-03-28T16:49:27Z","receivedAt":"2016-03-28T16:49:27Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Sat, Mar 26, 2016 at 3:13 AM, 惠轶群 wrote:\n> 2016-03-26 2:16 GMT+08:00 Junio C Hamano :\n>> 惠轶群 writes:\n>>\n>>> # Purpose\n>>> The current implementation of send-email is based on perl and has only\n>>> a tui, it has two problems:\n>>> - user must install a ton of dependencies before submit a single patch.\n>>> - tui and parameter are both not quite friendly to new users.\n>>\n>> Is \"a ton of dependencies\" true? \"apt-cache show git-email\"\n>> suggests otherwise. Is \"a ton of dependencies\" truly a problem?\n>> \"apt-get install\" would resolve the dependencies for you.\n>\n> There are three perl packages needed to send patch through gmail:\n> - perl-mime-tools\n> - perl-net-smtp-ssl\n> - perl-authen-sasl\n>\n> Yes, not too many, but is it better none of them?\n>\n> What's more, when I try to send mails, I was first disrupted by\n> \"no perl-mime-tools\" then by \"no perl-net-smtp-ssl or perl-authen-sasl\".\n> Then I think, why not just a mailto link?\n\nI think your proposal should clarify a bit who these users are that\nfind it too difficult to install these perl module dependencies. Users\non OSX & Windows I would assume, because in the case of Linux distros\ngetting these is the equivalent of an apt-get command away.\n\nIf installing these dependencies is hard for users perhaps a better\nthing to focus on is altering the binary builds on Git for platforms\nthat don't have package systems to include these dependencies.\n\nIn this case it would mean shipping a statically linked OpenSSL since\nthat's what these perl SSL packages eventually depend on.\n"},{"id":"282023","messageId":"CAKqreuy0RwgxqrRf7t1AU8dM2VtkvD9gd3VnzVRe-GEieVXDNA@mail.gmail.com","threadId":"41827","inReplyTo":"CACBZZX6q87dw6UW9z+2bAvvWu0WZcYCMD8gxW8MchHwd8Rv3kw@mail.gmail.com","subject":"Re: [GSoC] A late proposal: a modern send-email","fromName":"惠轶群","fromEmail":"huiyiqun@gmail.com","sentAt":"2016-03-29T04:17:55Z","receivedAt":"2016-03-29T04:17:55Z","isPatch":false,"sender":{"key":"huiyiqun@gmail.com","avatar":"https://gravatar.com/avatar/44aa01fbc2fb098682386b82a44aac03bd778275249228c55d09c5b6fe2fe0e0?d=mp&s=160"},"body":"2016-03-29 0:49 GMT+08:00 Ævar Arnfjörð Bjarmason :\n> On Sat, Mar 26, 2016 at 3:13 AM, 惠轶群 wrote:\n>> 2016-03-26 2:16 GMT+08:00 Junio C Hamano :\n>>> 惠轶群 writes:\n>>>\n>>>> # Purpose\n>>>> The current implementation of send-email is based on perl and has only\n>>>> a tui, it has two problems:\n>>>> - user must install a ton of dependencies before submit a single patch.\n>>>> - tui and parameter are both not quite friendly to new users.\n>>>\n>>> Is \"a ton of dependencies\" true? \"apt-cache show git-email\"\n>>> suggests otherwise. Is \"a ton of dependencies\" truly a problem?\n>>> \"apt-get install\" would resolve the dependencies for you.\n>>\n>> There are three perl packages needed to send patch through gmail:\n>> - perl-mime-tools\n>> - perl-net-smtp-ssl\n>> - perl-authen-sasl\n>>\n>> Yes, not too many, but is it better none of them?\n>>\n>> What's more, when I try to send mails, I was first disrupted by\n>> \"no perl-mime-tools\" then by \"no perl-net-smtp-ssl or perl-authen-sasl\".\n>> Then I think, why not just a mailto link?\n>\n> I think your proposal should clarify a bit who these users are that\n> find it too difficult to install these perl module dependencies. Users\n> on OSX & Windows I would assume, because in the case of Linux distros\n> getting these is the equivalent of an apt-get command away.\n\nIn fact, I'm not familiar with the build for OSX or Windows.\n\n> If installing these dependencies is hard for users perhaps a better\n> thing to focus on is altering the binary builds on Git for platforms\n> that don't have package systems to include these dependencies.\n\nWhy `mailto` not a good choice? I'm confusing.\n\n> In this case it would mean shipping a statically linked OpenSSL since\n> that's what these perl SSL packages eventually depend on.\n"},{"id":"282148","messageId":"CACBZZX4ezKtFqyC7bnNhtvcyEkXMr8_83u_p=zA0ZvqYipzNLQ@mail.gmail.com","threadId":"41827","inReplyTo":"CAKqreuy0RwgxqrRf7t1AU8dM2VtkvD9gd3VnzVRe-GEieVXDNA@mail.gmail.com","subject":"Re: [GSoC] A late proposal: a modern send-email","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2016-03-29T23:47:41Z","receivedAt":"2016-03-29T23:47:41Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Tue, Mar 29, 2016 at 6:17 AM, 惠轶群 wrote:\n> 2016-03-29 0:49 GMT+08:00 Ævar Arnfjörð Bjarmason :\n>> On Sat, Mar 26, 2016 at 3:13 AM, 惠轶群 wrote:\n>>> 2016-03-26 2:16 GMT+08:00 Junio C Hamano :\n>>>> 惠轶群 writes:\n>>>>\n>>>>> # Purpose\n>>>>> The current implementation of send-email is based on perl and has only\n>>>>> a tui, it has two problems:\n>>>>> - user must install a ton of dependencies before submit a single patch.\n>>>>> - tui and parameter are both not quite friendly to new users.\n>>>>\n>>>> Is \"a ton of dependencies\" true? \"apt-cache show git-email\"\n>>>> suggests otherwise. Is \"a ton of dependencies\" truly a problem?\n>>>> \"apt-get install\" would resolve the dependencies for you.\n>>>\n>>> There are three perl packages needed to send patch through gmail:\n>>> - perl-mime-tools\n>>> - perl-net-smtp-ssl\n>>> - perl-authen-sasl\n>>>\n>>> Yes, not too many, but is it better none of them?\n>>>\n>>> What's more, when I try to send mails, I was first disrupted by\n>>> \"no perl-mime-tools\" then by \"no perl-net-smtp-ssl or perl-authen-sasl\".\n>>> Then I think, why not just a mailto link?\n>>\n>> I think your proposal should clarify a bit who these users are that\n>> find it too difficult to install these perl module dependencies. Users\n>> on OSX & Windows I would assume, because in the case of Linux distros\n>> getting these is the equivalent of an apt-get command away.\n>\n> In fact, I'm not familiar with the build for OSX or Windows.\n\nThe core of your proposal rests on the assumption that\ngit-send-email's implementation is problematic because it has a \"ton\nof dependencies\", and that this must be dealt with by implementing an\nalternate E-Mail transport method.\n\nBut you don't go into how this is a practical issue for users exactly,\nwhich is the rest of the proposal. I.e. \"make it friendly for users\".\nLet's leave the question of creating an E-Mail GUI that's shipped with\nGit aside.\n\nCorrect me if I'm wrong but don't we basically have 4 kinds of users\nusing git-send-email:\n\n1) Those who get it from a binary Windows package (is it even packaged there?)\n2) Also a binary package, but for for OSX\n3) Users installing it via their Linux distribution's package system\n4) Users building it from source on Windows/OSX/Linux.\n\nI'm in group #3 myself for the purposes of using git-send-email and\nhave never had issues with its dependencies because my distro's\npackage management takes care of it for me.\n\nI don't know what the status is of packaging it is on #1 and #2, but\nthat's what I'm asking about in my question, if this becomes a\nnon-issue for those two groups (if it isn't already) isn't this\nquestion of dependencies a non-issue?\n\nI.e. why does it matter if git-send-email has N dependencies if those\nN are either packaged with the common Windows/OSX packages that most\nusers use, or installed as dependencies by their *nix distro?\n\n Group #4 is small enough and likely to be a git.git contributor or\ndistro package maintainer anyway that this issue doesn't matter for\nthem.\n\n>> If installing these dependencies is hard for users perhaps a better\n>> thing to focus on is altering the binary builds on Git for platforms\n>> that don't have package systems to include these dependencies.\n>\n> Why `mailto` not a good choice? I'm confusing.\n\nI'm not saying having this mailto: method you're proposing isn't good\nin itself, I think it would be very useful to be able to magically\nopen git-send-email output in your favorite E-Mail client for editing\nbefore sending it off like you usually send E-Mail.\n\nAlthough I must say I'd be seriously surprised if the likes of git\nformatted patches survive contact with popular E-Mail clients when the\nbody is specified via the body=* parameter, given that we're sending\npretty precisely formatted content and most mailers are very eager to\nwrap lines or otherwise munge input.\n\nI'm mainly trying to get to the bottom of this dependency issue you're\ntrying to solve.\n\n>> In this case it would mean shipping a statically linked OpenSSL since\n>> that's what these perl SSL packages eventually depend on.\n"},{"id":"282226","messageId":"alpine.DEB.2.20.1603301408380.4690@virtualbox","threadId":"41827","inReplyTo":"CACBZZX4ezKtFqyC7bnNhtvcyEkXMr8_83u_p=zA0ZvqYipzNLQ@mail.gmail.com","subject":"Re: [GSoC] A late proposal: a modern send-email","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-03-30T12:10:32Z","receivedAt":"2016-03-30T12:10:32Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 30 Mar 2016, Ævar Arnfjörð Bjarmason wrote:\n\n> Correct me if I'm wrong but don't we basically have 4 kinds of users\n> using git-send-email:\n> \n> 1) Those who get it from a binary Windows package (is it even packaged there?)\n\nIt is. And reportedly working fine. But in the pre-MSYS2 times it was a\nmajor pain in the butt due to the dependencies.\n\nCiao,\nDscho"},{"id":"282662","messageId":"20160405000306.GA4746@dcvr.yhbt.net","threadId":"41827","inReplyTo":"CAKqreuzE6G0WO4gn2_R7-QfZYfVS2tuAMEnwiVE8FyNviJGD+Q@mail.gmail.com","subject":"Re: [GSoC] A late proposal: a modern send-email","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2016-04-05T00:03:06Z","receivedAt":"2016-04-05T00:03:06Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"惠轶群 wrote:\n> 2016-03-28 6:00 GMT+08:00 Eric Wong :\n> > While Gmail provides SMTP access, it was (last I was told)\n> > incompatible with two-factor auth; so I've encountered users\n> > unable to send patches with their normal 2FA-enabled accounts.\n> \n> That's the origin of this idea of `mailto`.\n> \n> In fact, you could send mail via 2FA-enabled accounts via\n> \"app password\" metioned by Javier. But it's annoying to create\n> \"app password\" for every client.\n\nSince it seems possible to use 2FA with gmail, can either you\nor Javier submit a patch to Documentation/git-send-email.txt\nto update the Gmail-related section where\n\"Use gmail as the smtp server\" is to describe how to use this\n\"app password\"?\n\nIt's much easier to do than your entire GSoC proposal and would\nbe immediately useful to 2FA gmail users out there who don't\nknow this, yet or aren't running the latest git. Thanks.\n\n\n\n\n\n> \n> If there is a `mailto` method to send patch, you could type something\n> like\n> \n> git send-patch --mailto origin/master..HEAD\n> \n> Then, gmail is launched with the content of patch in it. You could edit\n> the list of `to` and `cc`(You could even take use of gmail contact). Then\n> just send. That's all. No need to SMTP config or \"app password\" any\n> more.\n> \n> > Maybe git hackers at Google have enough pull to lobby Gmail's\n> > web interface to make it easier to send plain-text patches;\n> > but I would love more to see users running local mail clients\n> > and even running their own SMTP servers.\n> \n> Yes, this should be free with user to pick their favorite mail client.\n> \n> >> That may not be a \"Git\" project, but GSoC is not limited to Git ;-)\n> >\n> > Completely agreed; email is critical to decentralized development;\n> > but I don't believe decentralization is in the best interests of\n> > any large and powerful corporation.\n> >\n> > IMHO, what we need is a SoIS: Summer of Independent Sysadmins :>\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n"}]}