Live data from Hacker News

Email and Git = <3

git-send-email.io

81–90 of 265 posts

Re: Email and Git = <3

#81

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…

Hard agree! I think the success of Github's PR system over Git + email workflows has proved itself quite well through sheer adoption numbers.

Re: Email and Git = <3

#82
post #38
post #11

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

This is honestly the best analogy.

Re: Email and Git = <3

#83
post #31

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

Isn't it weird that such people bother installing a windowing system at all? Just work off the login terminal bro, it's perfection.

Re: Email and Git = <3

#84
post #31

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…

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.

What on earth is "fake-usability"? It's more usable, just admit it.

Re: Email and Git = <3

#85

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…

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

Spent a long time not even knowing you can resolve merges in github. All I knew was magit and smerge, and assumed people with the fancier editors had something similar.

Re: Email and Git = <3

#86
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.

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.

Re: Email and Git = <3

#87
post #14

Earlier 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"! :)

AFAICT projects like OpenBSD still use the same infra: emailed patches and CVS (!).

Re: Email and Git = <3

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

Re: Email and Git = <3

#89
post #72

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

There is usually no need to subscribe.

Re: Email and Git = <3

#90
post #72

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

In what cases is it tricky? I find that most projects use some version of mailman (like QEMU - https://lists.nongnu.org/mailman/listinfo/qemu-trivial) and then it's just a question of filling out the form and hitting "Subscribe". I cannot remember project I wanted to contribute to, I had to use git+email and it was difficult to subscribe to the mailing list they want me to use.
Post reply on HN