From: Junio C Hamano <hidden> Date: 2016-06-15 23:08:58
惠轶群 [off-list ref] 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.
# 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.
- 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 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.
That may not be a "Git" project, but GSoC is not limited to Git ;-)
2016-03-26 2:16 GMT+08:00 Junio C Hamano [off-list ref]:
惠轶群 [off-list ref] writes:
quoted
# 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?
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?
quoted
# 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.
quoted
- 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 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.
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
That may not be a "Git" project, but GSoC is not limited to Git ;-)
Sorry, but I do not really mean to implement a general mail client.
In fact, this is a GUI front end for git send-mail and may be placed
under contrib/
On Sat, Mar 26, 2016 at 7:43 AM, 惠轶群 [off-list ref] wrote:
2016-03-26 2:16 GMT+08:00 Junio C Hamano [off-list ref]:
quoted
惠轶群 [off-list ref] writes:
quoted
# 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?
quoted
quoted
# 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?
quoted
quoted
- 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.
quoted
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
On Sat, Mar 26, 2016 at 7:43 AM, 惠轶群 [off-list ref] wrote:
quoted
2016-03-26 2:16 GMT+08:00 Junio C Hamano [off-list ref]:
quoted
惠轶群 [off-list ref] writes:
quoted
# 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?
quoted
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?
quoted
quoted
# 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?
No, if you could have termux a try, you will find that it's suitable for simple
development. it has a apt, so you could have clang, neovim, tmux, cmake
and so on.
In fact, I recently use my nexus 7 with termux as a portable
development environment.
A bluetooth keyboard is needed, of course.
quoted
quoted
quoted
- 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.
wxwidgets seems not a good choice. But if I build the GUI via web app,
I could import required js and css from Internet directly, so the users do
not need the dependencies on their computer.
quoted
quoted
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.
quoted
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 make it clearer:
1. there are so many great mail clients, why not let these experts to handle the
dispatch of mail?
For example, as a One-time-password user of gmail, I have to generate an app
password for each terminal device I'd like to send patch on.
It's more important that I could not use my favorite mail client which
has contact
list, familiar interface and more personal configuration.
Why not let one program just do one thing and do it best?
In my opinion, `mailto` is a suitable method. git is one of the best
version control
systems. So it forms basic structure of the mail according to the
patches and passes it
to the best mail client. How amazing.
2. But this workload is not enough for whole summer. I thought I could do other
interesting things based on the `mailto` link.
mail client is a straightforward choice.
In fact, I meant to implement an interface more friendly to new users.
no matter how
it is implemented or what it is based on. The first time I send patch
via gmail is not a
happy memory.
On Sat, Mar 26, 2016 at 7:43 AM, 惠轶群 [off-list ref] wrote:
quoted
2016-03-26 2:16 GMT+08:00 Junio C Hamano [off-list ref]:
quoted
惠轶群 [off-list ref] writes:
quoted
# 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?
quoted
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?
quoted
quoted
# 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?
No, if you could have termux a try, you will find that it's suitable for simple
development. it has a apt, so you could have clang, neovim, tmux, cmake
and so on.
In fact, I recently use my nexus 7 with termux as a portable
development environment.
A bluetooth keyboard is needed, of course.
This is not applicable to all people, but It make the git more free, isn't it?
quoted
quoted
quoted
quoted
- 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.
wxwidgets seems not a good choice. But if I build the GUI via web app,
I could import required js and css from Internet directly, so the users do
not need the dependencies on their computer.
quoted
quoted
quoted
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.
quoted
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
From: Eric Wong <hidden> Date: 2016-06-15 23:09:04
Junio C Hamano [off-list ref] wrote:
惠轶群 [off-list ref] writes:
quoted
- 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 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.
Another bigger problem is people rely heavily on webmail UIs
nowadays instead of running any local mail clients :<
While Gmail provides SMTP access, it was (last I was told)
incompatible with two-factor auth; so I've encountered users
unable to send patches with their normal 2FA-enabled accounts.
Maybe git hackers at Google have enough pull to lobby Gmail's
web interface to make it easier to send plain-text patches;
but I would love more to see users running local mail clients
and even running their own SMTP servers.
That may not be a "Git" project, but GSoC is not limited to Git ;-)
Completely agreed; email is critical to decentralized development;
but I don't believe decentralization is in the best interests of
any large and powerful corporation.
IMHO, what we need is a SoIS: Summer of Independent Sysadmins :>
From: Javier Domingo Cansino <hidden> Date: 2016-06-15 23:09:04
While Gmail provides SMTP access, it was (last I was told)
incompatible with two-factor auth; so I've encountered users
unable to send patches with their normal 2FA-enabled accounts.
Maybe git hackers at Google have enough pull to lobby Gmail's
web interface to make it easier to send plain-text patches;
but I would love more to see users running local mail clients
and even running their own SMTP servers.
Just in case, I use git send email with my gmail account and I have 2
step auth configured. The only "limitation" however is that you have
to create a password for each email client on it's own. If you own a
gmail account, go to
https://security.google.com/settings/security/apppasswords to create a
password for the email client.
--
Javier Domingo Cansino
2016-03-28 6:00 GMT+08:00 Eric Wong [off-list ref]:
Junio C Hamano [off-list ref] wrote:
quoted
惠轶群 [off-list ref] writes:
quoted
- 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 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.
Another bigger problem is people rely heavily on webmail UIs
nowadays instead of running any local mail clients :<
I know many heavily email user choose to migrate to client such as
alpine or mutt after using gmail for a long time.
While Gmail provides SMTP access, it was (last I was told)
incompatible with two-factor auth; so I've encountered users
unable to send patches with their normal 2FA-enabled accounts.
That's the origin of this idea of `mailto`.
In fact, you could send mail via 2FA-enabled accounts via
"app password" metioned by Javier. But it's annoying to create
"app password" for every client.
If there is a `mailto` method to send patch, you could type something
like
git send-patch --mailto origin/master..HEAD
Then, gmail is launched with the content of patch in it. You could edit
the list of `to` and `cc`(You could even take use of gmail contact). Then
just send. That's all. No need to SMTP config or "app password" any
more.
Maybe git hackers at Google have enough pull to lobby Gmail's
web interface to make it easier to send plain-text patches;
but I would love more to see users running local mail clients
and even running their own SMTP servers.
Yes, this should be free with user to pick their favorite mail client.
quoted
That may not be a "Git" project, but GSoC is not limited to Git ;-)
Completely agreed; email is critical to decentralized development;
but I don't believe decentralization is in the best interests of
any large and powerful corporation.
IMHO, what we need is a SoIS: Summer of Independent Sysadmins :>
On Sat, Mar 26, 2016 at 3:13 AM, 惠轶群 [off-list ref] wrote:
2016-03-26 2:16 GMT+08:00 Junio C Hamano [off-list ref]:
quoted
惠轶群 [off-list ref] writes:
quoted
# 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?
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?
I think your proposal should clarify a bit who these users are that
find it too difficult to install these perl module dependencies. Users
on OSX & Windows I would assume, because in the case of Linux distros
getting these is the equivalent of an apt-get command away.
If installing these dependencies is hard for users perhaps a better
thing to focus on is altering the binary builds on Git for platforms
that don't have package systems to include these dependencies.
In this case it would mean shipping a statically linked OpenSSL since
that's what these perl SSL packages eventually depend on.
On Sat, Mar 26, 2016 at 3:13 AM, 惠轶群 [off-list ref] wrote:
quoted
2016-03-26 2:16 GMT+08:00 Junio C Hamano [off-list ref]:
quoted
惠轶群 [off-list ref] writes:
quoted
# 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?
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?
I think your proposal should clarify a bit who these users are that
find it too difficult to install these perl module dependencies. Users
on OSX & Windows I would assume, because in the case of Linux distros
getting these is the equivalent of an apt-get command away.
In fact, I'm not familiar with the build for OSX or Windows.
If installing these dependencies is hard for users perhaps a better
thing to focus on is altering the binary builds on Git for platforms
that don't have package systems to include these dependencies.
Why `mailto` not a good choice? I'm confusing.
In this case it would mean shipping a statically linked OpenSSL since
that's what these perl SSL packages eventually depend on.
On Sat, Mar 26, 2016 at 3:13 AM, 惠轶群 [off-list ref] wrote:
quoted
2016-03-26 2:16 GMT+08:00 Junio C Hamano [off-list ref]:
quoted
惠轶群 [off-list ref] writes:
quoted
# 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?
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?
I think your proposal should clarify a bit who these users are that
find it too difficult to install these perl module dependencies. Users
on OSX & Windows I would assume, because in the case of Linux distros
getting these is the equivalent of an apt-get command away.
In fact, I'm not familiar with the build for OSX or Windows.
The core of your proposal rests on the assumption that
git-send-email's implementation is problematic because it has a "ton
of dependencies", and that this must be dealt with by implementing an
alternate E-Mail transport method.
But you don't go into how this is a practical issue for users exactly,
which is the rest of the proposal. I.e. "make it friendly for users".
Let's leave the question of creating an E-Mail GUI that's shipped with
Git aside.
Correct me if I'm wrong but don't we basically have 4 kinds of users
using git-send-email:
1) Those who get it from a binary Windows package (is it even packaged there?)
2) Also a binary package, but for for OSX
3) Users installing it via their Linux distribution's package system
4) Users building it from source on Windows/OSX/Linux.
I'm in group #3 myself for the purposes of using git-send-email and
have never had issues with its dependencies because my distro's
package management takes care of it for me.
I don't know what the status is of packaging it is on #1 and #2, but
that's what I'm asking about in my question, if this becomes a
non-issue for those two groups (if it isn't already) isn't this
question of dependencies a non-issue?
I.e. why does it matter if git-send-email has N dependencies if those
N are either packaged with the common Windows/OSX packages that most
users use, or installed as dependencies by their *nix distro?
Group #4 is small enough and likely to be a git.git contributor or
distro package maintainer anyway that this issue doesn't matter for
them.
quoted
If installing these dependencies is hard for users perhaps a better
thing to focus on is altering the binary builds on Git for platforms
that don't have package systems to include these dependencies.
Why `mailto` not a good choice? I'm confusing.
I'm not saying having this mailto: method you're proposing isn't good
in itself, I think it would be very useful to be able to magically
open git-send-email output in your favorite E-Mail client for editing
before sending it off like you usually send E-Mail.
Although I must say I'd be seriously surprised if the likes of git
formatted patches survive contact with popular E-Mail clients when the
body is specified via the body=* parameter, given that we're sending
pretty precisely formatted content and most mailers are very eager to
wrap lines or otherwise munge input.
I'm mainly trying to get to the bottom of this dependency issue you're
trying to solve.
quoted
In this case it would mean shipping a statically linked OpenSSL since
that's what these perl SSL packages eventually depend on.
From: Johannes Schindelin <hidden> Date: 2016-06-15 23:09:07
Hi,
On Wed, 30 Mar 2016, Ævar Arnfjörð Bjarmason wrote:
Correct me if I'm wrong but don't we basically have 4 kinds of users
using git-send-email:
1) Those who get it from a binary Windows package (is it even packaged there?)
It is. And reportedly working fine. But in the pre-MSYS2 times it was a
major pain in the butt due to the dependencies.
Ciao,
Dscho
From: Eric Wong <hidden> Date: 2016-06-16 02:18:40
惠轶群 [off-list ref] wrote:
2016-03-28 6:00 GMT+08:00 Eric Wong [off-list ref]:
quoted
While Gmail provides SMTP access, it was (last I was told)
incompatible with two-factor auth; so I've encountered users
unable to send patches with their normal 2FA-enabled accounts.
That's the origin of this idea of `mailto`.
In fact, you could send mail via 2FA-enabled accounts via
"app password" metioned by Javier. But it's annoying to create
"app password" for every client.
Since it seems possible to use 2FA with gmail, can either you
or Javier submit a patch to Documentation/git-send-email.txt
to update the Gmail-related section where
"Use gmail as the smtp server" is to describe how to use this
"app password"?
It's much easier to do than your entire GSoC proposal and would
be immediately useful to 2FA gmail users out there who don't
know this, yet or aren't running the latest git. Thanks.
If there is a `mailto` method to send patch, you could type something
like
git send-patch --mailto origin/master..HEAD
Then, gmail is launched with the content of patch in it. You could edit
the list of `to` and `cc`(You could even take use of gmail contact). Then
just send. That's all. No need to SMTP config or "app password" any
more.
quoted
Maybe git hackers at Google have enough pull to lobby Gmail's
web interface to make it easier to send plain-text patches;
but I would love more to see users running local mail clients
and even running their own SMTP servers.
Yes, this should be free with user to pick their favorite mail client.
quoted
quoted
That may not be a "Git" project, but GSoC is not limited to Git ;-)
Completely agreed; email is critical to decentralized development;
but I don't believe decentralization is in the best interests of
any large and powerful corporation.
IMHO, what we need is a SoIS: Summer of Independent Sysadmins :>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html