171–180 of 265 posts
Seems like you're sending plain text emails, no? I have links for websites, resume etc. in the signature so I am not sure how this is conducive to that. Unless there is a method to add a signature with links?
Earlier quoted context omitted.
I think GitHub was designed for getting work done, but since Microsoft bought them, they are slowly moving into enshitification territory. For example, they have a homepage that is just a wanna be social media feed and the file contents pages have ads for Copilot and in general there are ads for VSCode and blah blah. It was pretty good, but it's going to get much worse. :-)
I disagree on enshittification. The only practical change I've noticed in github usage is the improvements to code search, which has been unbelievably useful. It gives me the ability to do complex searches to find real usages of even the most obscure libraries, examples of poorly documented configuration files, and more, from any public repository hosted anywhere on github. That capability comes from both the large b…
"Enshitification" is rapidly becoming a meaningless term of disapproval, but it had a precise definition when Doctorow coined it:
> This is enshittification: surpluses are first directed to users; then, once they're locked in, surpluses go to suppliers; then once they're locked in, the surplus is handed to shareholders and the platform becomes a useless pile of shit.
GitHub directed a huge surplus to developers compared to what came before it. Microsoft bought it and worked on furthering the lock in with Actions, and now the ship is slowly moving towards wringing the extra value out of us. It's not at the bottom of the hill yet, but it's definitely on the slope. They already have ads for themselves on it. The ads are just going to slowly creep outwards as necessary to produce a smooth revenue curve.
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…
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…
Can somebody elaborate?
>Be advised that Protonmail is generally known to be a pretty bad email host. [...] Not to mention their mistreatment of open source and false promises of security! You should consider a different mail provider.
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…
I have absolutely no desire to send all of my companies intellectual property to a mail server. It could be the best workflow in the world, but if one email address gets breached, you're leaking everything and that's really unacceptable.
Earlier quoted context omitted.
> It drives away the kind of people who have little patience for technology problems and little patience for learning new things. like learning to use a GUI and a Web Interface?
It's not really that people can't use them. It's that they're slow, annoying, hard/impossible to automate, hard/impossible to customize and give you RSI. We've seen Web interfaces, they're hard to avoid. We've just decided that they're worse.
> the kind of people who have little patience for technology problems and little patience for learning new things
Also tell me how is tolerating rude incumbents of mailing list sending email with 50+ characters in a line a technical problem? (Yes they are often rude, and unwelcoming to those attempting to accept their anachronistic ways. You are demonstrating that specific behaviour right here, which many of us have encountered on those projects.)
I think the projects which accept contributions only from mailing lists will have their contributors die out, or will be forced to change their ways to survive. I for one will never again attempt to contribute to such project, thanks to the inflexibility of the incumbents I have faced several times. Also thanks to the sub-par review workflow, usually the lacking quick CI feedback.
Web UI might give you RSI, but the insufferable email-only-patches people give me PTSD from my previous encounters.
ps: if you are willing to learn new things, you can automate web apps and GUI apps (eg. Autoit, xaut). Some even have proper APIs (COM/dbus/web api), or a cli!
Personally, though, when I have to actually cut something, I use stainless steel knives or scissors, which are cheap and readily available and do a much better job. Same with pull requests. But historical reenactment can be a fun pastime.
The git-send-email part isn't too bad. It's everything else I have a problem with:
- You can't subscribe to a single PR/bug/feature-request thread. Subscription to the mailing list is all-or-nothing. And no, setting up email filters is not a reasonable solution.
- Email clients are pretty much universally terrible. Especially if you want to use the same client for your git flow as you do for regular email. Most clients don't handle inline-replies well, and require some extra work to send plain text emails. Clients that do work well for that often have a steep learning curve, and are missing features if you want to use it for general email.
- The flow for "Dealing with feedback" in this tutorial will start a new email thread instead of replying to the existing one. There is a way to reply to an existing thread with send-email, but it is kind of involved since you have to look up the message id of the email you are replying to (which may or may not be easy depending on your email client). And even then, I've had mixed success with it.
- Although I haven't been on the other side of it, it seems like reviewing the patch would be somewhat difficult without additional tooling. Especially comparing new versions dealing with feedback to the original version.
- Again, I haven't been on that side of it, but it seems like applying the changes from an email would be a bit of a pain compared to just pressing "merge".
- You can run into issues if your lines of code are more than 78 characters long. I used git-send-email to send in a patch once that had this, but the email client of the receiver couldn't handle long lines, so I had to resend it with the patch as an attachment.
- Some mailing lists require you to subscribe before you can send a patch. And if the list is pretty active, that can flood your inbox. See my first point.
- etc.
Earlier quoted context omitted.
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.
This is like saying that pyramids were constructed without modern cranes and bulldozers so obviously it's the right way to build stuff today. It's clearly not true but there are many power-wielding individuals in these projects who prefer to browse the web with lynx or develop in emacs and will impose this on anyone that would like to participate. This is wrong.