Hacker News Reader

80% of my interaction with github is via email. I and am sure most people once they get used to email workflows will find email lot more effective than the UI. It is true you can only comment via github officially today and not create a pull request itself.

It is trivial to use their read the email and use their API to create one. There are projects doing the other way [1] generating a email pull request.

If there were "open standards" for pull requests/ Merge requests then git should have implemented it as part of the protocol the transportation medium is explicitly left out of the protocol for a good reason.

[1] https://github.com/google/pull-request-mailer

If you only use emails for github issues and PRs, you’re missing edits made to comments after their publication.

>However, anyone who says there's no room to improve the onboarding experience, well, I just can't take their opinion seriously.

From TFA:

> I agree that the UX of email-driven development could be better!

This is followed by six examples of such improvements, the first of which is explicitly targeted at improving onboarding:

https://git-send-email.io

My man, those tools are great and I really respect the contribution of those tools to the community. But here's the kernel guidelines, which I am sure you are already familiar with: https://www.kernel.org/doc/html/latest/process/submitting-pa...

Even with the tooling you provided, it's still a crappy experience (maybe a little less with the Sourcehut stuff). I know it's easy to read into the comments and be like "well this person just wants to shove the kernel into Microsoft's product," but it doesn't have to be this way. The sad thing is, for better or for worse, Github can handle almost all of those steps in the patch submission process, save for the ones where you have to actually describe what's changing. that's like, 15 steps that a newcomer does not have to even deal with.

I think we all agree on "No Linux Kernel controlled by Microsoft platforms, please" but Sarah's comments that "this workflow sucks", and then your actions on "this workflow sucks" - y'all are saying the same thing.

These "15 steps" are 90% unrelated to the email workflow, and would not be solved by GitHub. Did you read this document? It's telling you how to be a good contributor and the mechanics of how to contribute. That being said, this documentation is sorely in need of a git-oriented overhaul, assuming the programmer isn't using git is not doing any favors for the 99% who are.

All of that vs git pull/push.. best of luck to your thing but that sounds absolutely horrible

This isn't a great take. I recorded a demonstration which shows the differences between the workflows more clearly:

https://spacepub.space/videos/watch/1619c000-7c44-4330-9177-...

After the initial setup, send-email is way faster.

I work at a web agency. Initial setup is frequent

I don't understand how those follow. Note that your "initial setup" follows you from project to project and even machine to machine if you sync your config files.

Ok that's fair and I overlooked a lot of it being a global config setup.

It still stands though that you can cut out an entire page and a half of your instructions with "step 4: git push origin main" for each repo

This isn't even taking into account getting other devs working with it, contractors we're working with, outside agencies that may be involved in this one

How do you even get the patch into the repo from an email? I couldn't see that instruction but may have overlooked that too

Watch the video I linked to, please.

You can't just `git push origin main` - you have to do that, then go to the web browser, create a fork, and open a pull request. And that's only if you already have a GitHub account. If you don't, add answering the registraiton email and adding your SSH key to those steps.

In your situation, having a single shared git repo might make sense, sure. But we're not talking about that, we're talking about code review strategies.

When I git push main it's instantly available and deployed to the live server(s) - but you're right I wouldn't push direct to main, I'd click the link that the push process output (Self hosted GitLab for context) and create a merge request

I've got a feeling I'll never properly see your point of view on this, as these tools exist and I'm not planning on dropping them for an unfriendly email version of the same, but I will give the video a proper as open minded as I can watch after work

I reckon you've never tried the email based tools. Ditch the assumption that they're unfriendly until you're knowledgable about it.

I felt your video was dishonest right from the start. If your password manager doesn’t easily meet those password requirements with default settings you need a new one.

Also who is registering a new account each time? I’m sure you recognise this argument :)

“I’ve got greylisting enabled on my server” which would affect your git email flow, but you don’t mention that. [edit: oooh, what about spam filtering? How many requests are lost to that?]

The slow back button presses as if it takes that long lmao. You’re proper at it.

Shocker you’re typing nice and smoothly in the email flow. Didn’t see that coming.

No mention of getting changes into the repo after receiving the email patch. Where’s your merge request equivalent? That step must be so easy and so much faster than using a web interface you just forgot to record it.

Context switching is moving a mouse to the other screen.. come on, just be real with me! I’m trying to learn your thing - just stick to it. Focus..

I’m sorry but this video contains too much bullshit and not enough info. I want to learn, not accept FUD. Hit me up with a clean version if you make one. May I suggest a side by side video edit?

At best they seem evenly matched. In which case I choose the path of inaction

You’ve gone from interesting tech person to PR spinner in my mind. Quite disappointing.

> You can't just `git push origin main` - you have to do that, then go to the web browser, create a fork, and open a pull request.

Not if you're using GitHub, because they have APIs for that:

    hub fork --remote-name origin
    git push origin feature
    hub ci-status --verbose
    hub pull-request

https://hub.github.com/

Install and learn how to use more third-party software to use a propreitary API on a centralized, proprietary, unreliable service... or just use the built-in git tooling?

Where is the builtin git tooling for showing side by side diff with proper syntax and different parts highlighting, and make it possible to turn my review comments back to the "bottom-posting" style text emails interleaved with the inline diff everyone on the mailing list strongly insisting? I'm sorry but I'm a stupid noob and my eye is not able to parse codes without syntax highlighting.

It's called your email client.

> And that's only if you already have a GitHub account.

Come on, I get that you hate being locked in a proprietary service which requires an "account", but if you want to make this point then I'm sure people could say "And that's only if you already have an email" and your tutorial should include setting up your own mail server.

Come on, I know that you hate the idea of facing your cognative dissonance, but there are different things.

When was the last time you met someone who didn't have an email account? And you can set up an email address on any of dozens of email providers, and use them to communicate with any of the rest. I can't sign up on GitLab and use that account to post on GitHub.

Using plain-text email for sending patches is fundamentally broken because it's just not a reliable transmission medium. SMTP is very old and very moldy and it's not something that you want to force your contributors should deal with.

The first step is to always push you candidate commits to another inside a public git repo first. Unlike email the protocols underneath git push (ssh or https) are easy to use and operate reliably in all circumstances.

> Email has worked for the Linux dev community for decades and that should be protected and not disrupted.

No, it's wrong to protect workflows simply because they "old". There are many web-based code review solution out there and most of them are preferable to email.

OLD == BAD

No, wrong. SMTP works fine and has done so for a long time, and it's incredibly easy to set up. It's the least of your problems when the rest of your task is patching the freaking Linux kernel.

And as far as reliabilty is concerned, SMTP is one of the most reliable protocols on the internet. Compare with this:

https://www.githubstatus.com/

SMTP is terrible, especially for people with corporate accounts behind firewalls. I've contributed to linux in the past and dealing with corporate IT was a miserable experience and saw lots of other kernel developers waste their time fiddling with SMTP parameters.

Those same firewalls can pass https or git+ssh just fine, it "just works". SMTP is not worth dealing with.

Email is also not very good as a forum, for example you can't edit your posts for spelling fixes, archives are unreliable and hard to browse and it's difficult to map git commits to reviews.

It's also wrong to claim that linux code review is somehow "distributed", it is very much centralized on a couple of mailing lists servers on vger.org.

It would be much better if kernel maintainers kept their trees on github and started accepting PRs.

Your corporate firewall being run by morons has nothing to do with what's a good or bad protocol. A lot of people have the SSH port blocked, and git:// too. By your argument we shouldn't be doing literally anything on any port other than 443.

>Email is also not very good as a forum, for example you can't edit your posts for spelling fixes

So what? You learn to get it right. There are other advantages to emails that forums don't have, like...

>archives are unreliable

This utter bollocks. Archives are plenty reliable and everyone on the list has their own copy of everything. Many mailing lists are mirrored mulitple times. You simply cannot do this on GitHub.

>it's difficult to map git commits to reviews

Fair that this could be improved, but it's not exactly difficult. You can just search your mail archives for the subject line, or even just google it. Still, it could be improved.

>It's also wrong to claim that linux code review is somehow "distributed", it is very much centralized on a couple of mailing lists servers on vger.org.

Hundreds of mailing lists, not all of which are on vger.org, and some of the development doesn't take place on mailing lists at all. Some of it takes place on GitHub!

It's not problem of SMTP or email in general that Outlook is trash. I get it, ages ago you bought into Microsoft's ecosystem, but can't you acknowledge it's flaws? If the server you're using doesn't let you send emails the way you want to, it's the problem of the server, not the email ecosystem in general.

Problems with corporate SMTP are widespread and configuring your own gets you easily marked as spam. The email ecosystem is very old and not very good and it's better to avoid relying on it entirely.

Fuck plain-text email.

OLD == BAD

SMTP is not just OLD, it is genuinely BAD

So far your only justification for this has been that your employer has a shitty firewall.