I appreciate the effort here, but after learning the workflow and having to get all this set up on a few computers, having to configure git send-mail is honestly just needlessly annoying and absurd. Organizations that insist on using workflows like git send-mail and mailing lists not only drive away a significant number of potential contributors, but they also form a weirdly religious culture that fetishizes needless…
Email and Git = <3
81–90 of 265 posts
Re: Email and Git = <3
#82Earlier quoted context omitted.
This is my experience as well. I love the hacker culture associated with it and it's very fun to use e.g. Mutt, sr.ht, and git-send-email together, but it's anything but efficient and straightforward. I ultimately moved away from sr.ht for that reason.
Some, like myself, find the mouse really painful to use and hate graphical interfaces when you have to randomly click to find something (while you can read a man page, grep through it and then automatize the process in custom scripts). But it is not only about efficiency. It is about control and centralisation. Git-send-mail works everywhere there’s an email. It allows people to use the tool they prefer. It allows th…
Re: Email and Git = <3
#83Earlier quoted context omitted.
Organizations that insists on using a web interface and ever-changing click workflows not only drive away a significant number of very knowledgeable contributors, but they also form a weirdly irrational culture that fetishizes needlessly graphical content, marketing and fake-usability detrimental to learnability and integration with each user workflow.
GUI is fake-usability now? Fake Edit: Oh this is HN. Never mind then.
Re: Email and Git = <3
#84I appreciate the effort here, but after learning the workflow and having to get all this set up on a few computers, having to configure git send-mail is honestly just needlessly annoying and absurd. Organizations that insist on using workflows like git send-mail and mailing lists not only drive away a significant number of potential contributors, but they also form a weirdly religious culture that fetishizes needless…
Organizations that insists on using a web interface and ever-changing click workflows not only drive away a significant number of very knowledgeable contributors, but they also form a weirdly irrational culture that fetishizes needlessly graphical content, marketing and fake-usability detrimental to learnability and integration with each user workflow.
Re: Email and Git = <3
#85Earlier quoted context omitted.
Did you contribute to open source in those days? I did a little (KDE patches to mailing lists before I got Subversion access) and: it was _awful_. You think merging/rebasing/resolving conflicts is a pain now? Doing the same thing via email was _so_ much worse. GitHub has made some parts of open source worse (e.g. how easy it is to now open poor issues while ignoring required information compared to Bugzilla) but the…
> You think merging/rebasing/resolving conflicts is a pain now? Doing the same thing via email was _so_ much worse. Email is just used to receive the patch, you should use a tool meant for the job to actually do the merge. I realize that is probably not what you meant though. Besides, when email patching first began, the tooling was in its infancy. However; today tools like the git cli itself, or magit + smerge-mode…
Re: Email and Git = <3
#86Earlier quoted context omitted.
There are instructions provided for Gmail and some others: https://git-send-email.io/#step-2 A tool from Google is mentioned and linked to: https://github.com/google/gmail-oauth2-tools/tree/master/go/...
That uses app specific passwords, and with Google Workspace, the administrator can completely turn off these “less secure apps”. Pretty sure Office 365 has the same.
Re: Email and Git = <3
#87Earlier quoted context omitted.
If it was so long ago, it likely predates git, and was more painful than it is now. (Git was introduced in 2005, while Linux was first released in 1991; fourteen years separate them.)
Indeed, you're right! Yet people still sent patches over email back then, and that is what I meant with "this was how they did it"! :)
Re: Email and Git = <3
#88Re: Email and Git = <3
#89Earlier quoted context omitted.
Configuring git send-email is trivial, definitively faster than creating an account at some web UI from a "source forge" – it's literally setting a handful of properties in the `.gitconfig` – and those are not specific to a project, but just your mail server settings you can reuse them for any project that accept patches over mailing lists. And using it for a project that accepts this workflow is such a joy, no need…
> Configuring git send-email is trivial, definitively faster than creating an account at some web UI from a "source forge" . You forgot that mailing list requires subscription and in some cases it could be a tricky. Without proper subscriptions and confirming subscription, your mails with patches will go to trash.
Re: Email and Git = <3
#90Earlier quoted context omitted.
Configuring git send-email is trivial, definitively faster than creating an account at some web UI from a "source forge" – it's literally setting a handful of properties in the `.gitconfig` – and those are not specific to a project, but just your mail server settings you can reuse them for any project that accept patches over mailing lists. And using it for a project that accepts this workflow is such a joy, no need…
> Configuring git send-email is trivial, definitively faster than creating an account at some web UI from a "source forge" . You forgot that mailing list requires subscription and in some cases it could be a tricky. Without proper subscriptions and confirming subscription, your mails with patches will go to trash.