Live data from Hacker News

Email and Git = <3

git-send-email.io

131–140 of 265 posts

Re: Email and Git = <3

#131
post #42
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.

“needlessly graphical” requires a citation when it’s clear that if you use a web GUI for this you address a market of potential contributors that is three to six orders of magnitude larger. srht is really designed for (and thus only really useful for) lone wolf developers who collaborate rarely, if ever, and with a very small number of collaborators who collaborate infrequently. It is not built for large teams with c…

Some of the largest and most important software is developed over email, e.g. Linux, QEMU, Firefox, etc... Don't make the mistake thinking that email doesn't scale. In fact, for most teams, the opposite is true.

Re: Email and Git = <3

#132
Oh, I thought this was like a PR notification system, it's to actually send the diff to an email list. And the recipients would pull in those changes from the email? I think that's kind of how things worked a long time ago IIRC. Is the goal that this would be as official as how we push to remote, then file a PR now?

Actually, if you want to cut out all the systems like github or git lab, why wouldn't the team just set up a VPS with standard ssh access and that would be the main repo people push to since git supports many protocols like ssh, and even file:// (which I use for my local projects which are backed up).

It's easy for the VPS admin to add new team members, just a standard Linux account. It might be possible to even set up a restricted account so the member ssh'ing in a commit using git only has access to the repo and can't get a login shell.

Re: Email and Git = <3

#133
post #90

Earlier quoted context omitted.

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.

And then every so often mailman hits you up with "I'm receiving all these bounces from your email server!" because all the various garbage anti-spam techniques were not quite thought out with mailing lists in mind or people have lots of misconfigured servers and servers with different acceptance criteria, and it's all a big mess. Configuring git send-email is only half the battle, anyway - chances are you want to par…

That's a battle??

This sounds like hyperbolic brought on by dislike, not a real indicator of time cost/effort. You've already spent more time complaining, than the work done to do these things!

Re: Email and Git = <3

#134
post #100

Earlier quoted context omitted.

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

There's complexity and then there's complexity. Your end user experience as a Discord user may be simpler on its face, but it's reliant on a lot of obfuscated complexity under the hood. You wouldn't be able to, say, send Discord messages using telnet, the way you can with IRC. Discord's simplicity in setting up an account, joining servers, having scrollback, etc comes at the cost of other types of simplicity. People…

your parens enclose the most unneeded addendum i have ever seen

Re: Email and Git = <3

#135

Earlier quoted context omitted.

Damn, this is ugly and confusing, I mean, look at the threads XD! I'm glad I must not use this shit.

Shh now. A basic interface that took 5 minutes to make in 1995 is good enough for all eternity. No need to change it.

I certainly love navigating a million times back and force to read what should be a single thread.

Re: Email and Git = <3

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

When you treat your inbox as a work queue and aim for zero, it's easy to be productive from within your inbox

Re: Email and Git = <3

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

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

Argitrage?

Re: Email and Git = <3

#138

Earlier quoted context omitted.

There's complexity and then there's complexity. Your end user experience as a Discord user may be simpler on its face, but it's reliant on a lot of obfuscated complexity under the hood. You wouldn't be able to, say, send Discord messages using telnet, the way you can with IRC. Discord's simplicity in setting up an account, joining servers, having scrollback, etc comes at the cost of other types of simplicity. People…

“Obfuscated complexity” aka good UX that decreases friction and increases velocity.

Again, friction and velocity of what? It's a lot easier for me to write an IRC bot than a Discord bot. But other things are much harder to do with IRC. People are looking at different vectors.

Re: Email and Git = <3

#139

Earlier quoted context omitted.

There's complexity and then there's complexity. Your end user experience as a Discord user may be simpler on its face, but it's reliant on a lot of obfuscated complexity under the hood. You wouldn't be able to, say, send Discord messages using telnet, the way you can with IRC. Discord's simplicity in setting up an account, joining servers, having scrollback, etc comes at the cost of other types of simplicity. People…

your parens enclose the most unneeded addendum i have ever seen

That's surely hyperbole. You can just say "This is unnecessary" and it achieves the same purpose. Maximalist comments like this tend to amplify the tension in these sorts of discussions.

Re: Email and Git = <3

#140
post #90

Earlier quoted context omitted.

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.

How is that harder than signing up to Github?

Personally, it's not. I'm using GitHub and I also sometimes send patches in emails.

I'm asking specifically what part of subscribing to mailing lists is the tricky part, as that's what parent mentioned. I'm not saying it's easier/harder than GitHub's workflow.

Post reply on HN