[keepamovin]

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!

[mikemcquaid]

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 contribution side is so much nicer now.

(Bias/context: former GitHub employee, former KDE committer, current Homebrew project leader)

[bombcar]

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)

[mikemcquaid]

I live in my email client and only use GitHub's email notifications. When I was working at GitHub and watching Homebrew/homebrew-core: I would regularly get >1000 a day.

I still do not miss the days of doing patch management from my email client :)

[nunez]

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

[keepamovin]

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

[Hackbraten]

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

Argitrage?

[dustfinger]

> 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 (my personal preference) are as good as GitHub, if not better. I never actually use GitHub for merging, even when working on projects hosted in GitHub.

[beepbooptheory]

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.

[mikemcquaid]

> Email is just used to receive the patch, you should use a tool meant for the job to actually do the merge.

I know because I also actually did this.

You still had to do this locally and then turn it into an email and had no real indication whether someone else had seen/tried/reviewed/etc. it

> However; today tools like the git cli itself, or magit + smerge-mode (my personal preference) are as good as GitHub, if not better.

I can totally believe for you: this is the case. For most people, though: it will not be. Feel free to prove me wrong by creating a(nother) project that gets thousands of contributors entirely through email.

(If you're actually Linus Torvalds, though: you win, I'll shut up now)

[ploum]

I had the exact opposite experience.

I’ve never managed to understand how to all those things, always switching between github web UI, github tools, command-line github. Everything was a mess.

Then I left github for sourcehut and managed to read a book about git.

It is still hard but now, everything makes so much sense. When I have a problem, instead of clicking everywhere and blindly copy/pasting results from stackoverflow, I actually think about my problem and what result I want to have.

Yes, the upfront effort is harder. It is like learning Vim or Emacs. It’s hard for the first few days/weeks then you get a lifetime of incredible benefits.

(Bias/context: I’m the author of https://ploum.net/2023-02-22-leaving-github.html )

[gilcot]

You were a github consumer.

You are now a git user.

[keepamovin]

Ha! I love your bias disclaimer -- and you have certainly brought Homebrew out of the darkages (no disparagement to the earlier works); it's noticeably more performant lately. :)

Your skepticism is understandable! GH seeks to bring this collab to all, but back then the skill required to even contribute was a barrier. But in a way that barrier was acceptable and useful.

The people doing it were skilled. The basic level of skill required to even contribute was a lot. I think there’s something to that.

As a 14-year-old it was beyond me, or so I thought, but in truth it probably wasn’t. But yep, you got me; I did not contribute! I was an observer, with a genuine admiration for the simplicity and effectiveness of that method of contribution. How sending something as commonplace as an email can have profound implications when it carries a valuable contrib!

Indeed GH has some joy. Yet while convenient, modern tools might lack the intimacy and individualism of the older, more decentralized methods, which can avoid the immediate public scrutiny that GH may entail.

I suppose you can consider my words an ode to the old ways, and an invitation to consider whether some elements of the past should be reintroduced in today's collaborative environs. This might sound whimsical (and perhaps not entirely accurate), but perhaps the "email method" was even more eco-friendly!

It's not so much I think those things you list are a pain, just the overall "structure of collaboration and social organizing algorithms" (please excuse me; I'm finding this hard to articulate!).

If don't get the vibe of my comment, I totally understand! It's intended to resonate with those who witnessed the evolution of dev practices and share my nostalgia for the early internet of the 90s.

My memories of watching patches flying over those email lists are forever tied up with that whole early internet nostalgia. I loved that stuff. I read zines, and printed off RFCs so I could smuggle them to school and read them, just to “stay in touch” with online, even when we couldn’t connect. :)

[mikemcquaid]

Thanks for the kind words!

> As a 14-year-old it was beyond me, or so I thought, but in truth it probably wasn’t.

Eh, maybe it was, maybe it wasn't! I didn't do any meaningful open source contribution until the tail end of university/college.

> I suppose you can consider my words an ode to the old ways, and an invitation to consider whether some elements of the past should be reintroduced in today's collaborative environs.

A great idea and always worth considering <3

[js2]

I've been contributing to open source projects since the late 90s. I never found the mailing list workflow awful. I also don't find merging/rebasing/resolving conflicts to be much of an issue, and I say this as someone who spent a couple years keeping my company's fork of Chromium rebased on-top of Chromium. Okay, that was a bit of a pain, especially when a new engineer joined Chromium and decided they just had to refactor an entire subsystem.

[pxc]

> You think merging/rebasing/resolving conflicts is a pain now? Doing the same thing via email was _so_ much worse.

Wait, are people doing this via the GitHub web UI these days? That sounds like a nightmare.

[mikemcquaid]

You can do some of this through the GitHub web UI and sometimes I do that.

I didn't say that, though, so I'm not sure where you're coming from here.

[pxc]

Ah, so it's more about having a git remote to run `git pull` or `git rebase` against than the forge-specific stuff.

[dewey]

> Hackers, working alone, late at night, strange times, strange places. Cultivating their work and skills and then ... shoot ... sending an email!

Very poetic, but also not much different to the current state. Just clicking to open a PR instead of sending an email attachment.

[keepamovin]

:) Thank you!

I guess I prefer text. And deeply there's a difference between staying in text, and moving to GUI. The medium is the message^0, and even if the process is "the same", everything becomes different because you're no longer within the text world.

0: https://en.wikipedia.org/wiki/The_medium_is_the_message

[dewey]

I know it's not the same, but that's also why I prefer GitLab's "--push-option=merge_request.create" which creates a PR from the CLI without needing me to open the website and clicking a button. I'm still annoyed daily that this doesn't exist for GitHub.

[dnsmichi]

Thanks for sharing. GitLab team member here.

More GitLab push options are documented in https://docs.gitlab.com/ee/user/project/push_options.html

You can also add a parameter to merge the merge request when the pipeline succeeds. This can be handy for quick fixes that do not require reviews, and avoids unnecessary context switches.

# mwps BRANCHNAME

alias mwps='git push -u origin -o merge_request.create -o merge_request.target=main -o merge_request.merge_when_pipeline_succeeds'

Example from https://gitlab.com/sytses/dotfiles/-/blob/master/git/aliases... and https://about.gitlab.com/blog/2021/10/19/top-10-gitlab-hacks...

If you prefer deeper CLI integration, suggest installing the GitLab CLI: https://docs.gitlab.com/ee/editor_extensions/gitlab_cli/

[pjm331]

GitHub has a CLI https://cli.github.com/manual/gh_pr_create

[dewey]

Yes, but the advantage with the "push options" is that I can put it in my .gitconfig and it just works automatically when I do a git push without using some proprietary platform's cli.

[nkjoep]

correct. Opening a PR triggers an email. No difference at all.

[terminalcommand]

Many oss projects still do this, don't they. I am subscribed to debian and python mail lists. Debian's lists are highly active.

[keepamovin]

I guess there must be a reason for that! It could just be most are used to that way, but I'd like to believe it's somehow "better"! haha :)

[rightbyte]

E.g. GCC does it by mail.

[yankput]

sr.ht does that

I don’t find it very user friendly (well, at all), but if you want a git forge that does that, you can use it.

[junon]

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.

[ploum]

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 them to build custom tools. It doesn’t make people dependent from a forge (you are a simple "git remote set-url" away from using a new forge).

Github forces everybody to use the same graphical interface which requires tons of JS and lot of CPU. Github forces you to accept all their changes. Github forces you to be a slave of Microsoft and contribute all your code to their IA training set. Github forces you to be notificed of stuff you don’t care.

The "Hacker culture" is first and foremost about personal freedom. And if you believe the tool are not efficient, as a true hacker, you will built others (but, spoiler, most of the time, when you become proficient enough to build you own tools, you realize how efficient the existing ones are).

Hacking is like walking. You look at walkers and you think it looks tiring to walk. So you go to the parking lot. You start your car. You go through the gate and give your driver license to the cop controlling you. You then go to the gas station. You pay with you credit card. There’s an accident in front of you, you are stuck in the traffic. You take your Google controlled GPS and ask for another itinerary. You drive. You wait at a red light, looking at your phone. A notification to pay the insurance of the car. Another one to pay for the leasing of the car itself. A light blink on the dashboard: you need to add oil and do the annual checkup of the car. You drive, you are a bit stressed and go too fast. You see a flash. Shit! Will I get a ticket? I was not that fast? You arrive at destination. There’s no room left in the parking. You start to drive around, hoping for a spot. There! You get it. It is bit small. You hope that nobody will scratch your car. For whatever reason, you learned that cars can’t be scratched so you are very careful. You get out of the car and walk a bit to the destination. Then you see them… The walkers. They went here by foot, through a path in the forest. They are smiling, even if they was some light rain.

And you ask them:

"Why don’t you guys get a car? Seriously? Walking is hard and inefficient. I can’t walk myself for than 1km before getting my legs sore."

[fsociety]

> … GitHub forces you to be a slave of Microsoft … Relax, the hyperbole is out of control here. I use GitHub and am certainly not a slave.

[keepamovin]

I think the value of alternate communication systems is not to be underestimated. And bravo for recalling the heartfelt connection between personal freedom and hacker culture! You are certainly "walking the walk!" :)

[junon]

I really don't disagree with you at all. I also don't like GitHub anymore nor have I ever liked Microsoft (see my last few comments on HN on recent threads, in fact).

I don't blame anyone for using it either, just didn't fit my personal workflow like mouse-based doesn't fit yours.

[NoGravitas]

This is honestly the best analogy.

[Semaphor]

I contributed to a project using this, once. I decided that unless I’m highly invested, it’s just not worth the hassle.

[bitofhope]

This site seems to be made by Drew DeVault who also runs sourcehut.

[yankput]

Didn’t notice that.

But makes sense.

[nine_k]

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

[keepamovin]

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

[nine_k]

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

[keepamovin]

Indeed they do. There's impressively many heavy-duty projects that use it. A great many OSes. There's certainly something to it! :)

[nine_k]

Certainly! For one thing, CVS does not allow for such easy rebases and merges as git, so someone has to read your patch carefully, make certain that it merges cleanly, and otherwise pay more attention. This may result in a slower pace, but also in less breakage and a larger shared understanding.

[keepamovin]

Nice! Yeah, CVS, I don't know much about it, but your comment reminds me I should check out things outside the git ken! They might just have valuable understandings I need to learn! Thanks for letting me know about it :)