101–110 of 265 posts
Earlier quoted context omitted.
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 (!).
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…
I don't blame anyone for using it either, just didn't fit my personal workflow like mouse-based doesn't fit yours.
Earlier quoted context omitted.
AFAICT projects like OpenBSD still use the same infra: emailed patches and CVS (!).
Indeed they do. There's impressively many heavy-duty projects that use it. A great many OSes. There's certainly something to it! :)
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…
> 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.
I'm trying to subscribe to Discord. I'm currently stuck in a captcha loop.
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…
It drives away the kind of people who have little patience for technology problems and little patience for learning new things.
I don't want those kind of people working on e.g. Git. Git needs people who have lots of patience for technology problems and lots of patience for learning new things.
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…
> 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.
People in this thread are talking past each other without realizing that they are expressing different preferences about where complexity belongs in a tool.
(For the record, I happen to be on the IRC / git mailing list side of the spectrum.)
Earlier quoted context omitted.
> 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.
Configuring git send-email is only half the battle, anyway - chances are you want to participate in the discussion of your patch, so better figure out how to make sure your email client will not send the forbidden HTML email.
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.
For most channels you don't need an IRC account. And there are web interfaces like https://web.libera.chat/ . I'm trying to subscribe to Discord. I'm currently stuck in a captcha loop.
Clicking a link to open a chatroom directly, with no account creation process, is infinitely simpler than account creation, potentially with several layers of verification (CAPTCHA, email, phone verification to join a server...).
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…
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…
> not only drive away a significant number of potential contributors, It drives away the kind of people who have little patience for technology problems and little patience for learning new things. I don't want those kind of people working on e.g. Git. Git needs people who have lots of patience for technology problems and lots of patience for learning new things.
There’s having patience and problem-solving ability, and there’s not seeing the value in jumping through the various hoops that comprise some ‘90s Internet fetishist’s playground.
This is all just code for “I’m old, set in my ways, and don’t appreciate the fact that the only reason I find my workflow easier is because I know it, not because it’s more intuitive than what people are doing these days”.