Live data from Hacker News

Email and Git = <3

git-send-email.io

91–100 of 265 posts

Re: Email and Git = <3

#91
post #54

Earlier quoted context omitted.

“Want to contribute? Subscribe to our mailing list that sends a hundred emails a day.” Nope.

Subscribe to our mailing list, where we are rude and dismissive if you accidentally dare make a line longer than 50 characters, (didn't you read our netiquette?) as some members like to read their emails on outdated devices without text reflow capable display software. Also don't dare to use non-ASCII Unicode characters, or we will be rude and will ignore your request. Just spell your name in American, because that i…

Even better is when people post issues on Reddit or whatever asking for help because that's the most low friction way for them to ask, and then a project contributor replies with "hey can you send this to the mailing list?" and so the person sends it in and is met with exactly fucking this. It's just such a great use of everyone's time.

Re: Email and Git = <3

#92

I love this. This is how it was done back in the days of usenet. People would email patches to the linux kernel. Hackers, working alone, late at night, strange times, strange places. Cultivating their work and skills and then ... shoot ... sending an email! Their contribution. So cool! Maybe we should go back to this. Get rid of the whole github thing. Every group their own little mailing list. Laboring in private!

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…

One thing I’ve noticed is that the people who “live in their email client” (and this applies to Outlook and to using emacs to read email) are very productive if everything is working right. I’ve seen people blow through a number of patches and discussions in their email client faster than I can even get GitHub to load the notifications.

And then there’s a philosophical discussion if burning newbie’s time or discouraging them is worth making the old guard’s time more productive- including discouraging interactions entirely.

(This is why for certain projects you can be entirely useful even if you can’t code; just as an intermediary)

Re: Email and Git = <3

#93
post #61
post #56

Earlier 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.

The tool from Google that is linked to appears to use oauth2.

Re: Email and Git = <3

#94
post #86
post #61

Earlier quoted context omitted.

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.

There’s another method that doesn’t use app specific passwords but I’m not entirely sure how it DOES work - it opens a connection and then gives you a web address to go to in your browser to authenticate with 2fa. And then somehow it magically works until it decides it doesn’t like you anymore.

I never studied the protocol of Gmail/Exchange/etc. 2FA, but I suppose the SMTP auth token expires after a while, and the client somehow hasn't implemented token refresh? Anyway, glad to know there is a way (?) to get git-send-email working with stricter 2FA.

Re: Email and Git = <3

#95
post #54

Earlier quoted context omitted.

“Want to contribute? Subscribe to our mailing list that sends a hundred emails a day.” Nope.

You don't need to subscribe. You are in CC when people want you to be notified, otherwise there are web interfaces you can browse. See https://lists.gnu.org/archive/html/guix-devel/ for example. On each message there is a button: "reply via email to [...]".

This interface is awful. I wish GNU would make more of an effort to be easy to contribute to.

Re: Email and Git = <3

#96
post #61
post #56

Earlier 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.

Sadly you’re right. Microsoft has brainwashed many IT departments into forcing oauth on everything, no app specific passwords, no regular passwords, nothing else. Thankfully they do support this on imap and smtp, but you have to have something that can handle it. I use a modified version of isync with the sasl plugin to fetch mail, and a python smtp sender that supports the oauth flow along with a set of scripts for generating a new refresh token every few months. It’s a heck of a lot of stuff to maintain, but at least it works. If anyone’s interested I could provide links or upload the modified versions to fix o365 quirks.

Re: Email and Git = <3

#97

Earlier quoted context omitted.

You don't need to subscribe. You are in CC when people want you to be notified, otherwise there are web interfaces you can browse. See https://lists.gnu.org/archive/html/guix-devel/ for example. On each message there is a button: "reply via email to [...]".

This interface is awful. I wish GNU would make more of an effort to be easy to contribute to.

I usually know, when the interface is not too shiny, that the content might be good. It's the same with HN. And those interfaces are still very easy to understand and use.

That being said, there is certainly room for improvement.

Re: Email and Git = <3

#98
post #88

Is there any collaboration tool (reviews, etc.) that uses git itself to sync the status? Adding email or whatever seems unnecessary, and github et al. seem contrary to the spirit of git.

In theory modern Gerrit supports this, by storing review metadata in Git notes attached to the repository. Most of the time though, people still use the Web UI.

Re: Email and Git = <3

#99
post #92

Earlier 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…

One thing I’ve noticed is that the people who “live in their email client” (and this applies to Outlook and to using emacs to read email) are very productive if everything is working right. I’ve seen people blow through a number of patches and discussions in their email client faster than I can even get GitHub to load the notifications. And then there’s a philosophical discussion if burning newbie’s time or discourag…

I think the focus of attention that this workflow offers certainly has its advantages. There's likely a variety of factors at play, however!

Re: Email and Git = <3

#100

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…

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…

> not the monsters that GitHub/Lab

You mean cloning a repo and then simply pushing upstream?

I can’t fathom how anyone would think that is more complicated than e-mail push workflows.

It’s like someone telling you that IRC is “obviously” less complicated than setting up a Discord account.

Post reply on HN