Live data from Hacker News

Email and Git = <3

git-send-email.io

201–210 of 265 posts

Re: Email and Git = <3

#201

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…

> improvements to code search

The enshittification related to this feature includes:

(1) Code search is no longer available without being logged in to GitHub--even if the search is restricted to a single repository.

(2) This is compounded by GitHub "recently" started requiring additional steps in the authentication process for certain types of accounts without providing any option to opt-out (e.g. by choosing to restrict the account to being read-only/search-only/issue-only going forward).

There is no dialogue, you accept whatever new restrictions/requirements are put in place or you lose access to the account which you were "convinced" to use to contribute & interact with FLOSS projects over the past N years.

(What other choice do you have? Convincing every single FLOSS project to move from GitHub to...? Good luck!)

Re: Email and Git = <3

#202

Earlier quoted context omitted.

> I prefer to use a monster that actually has security mechanisms, and protocols in place designed by professionals. Like a mail server?

I don't know, sending sensitive information over plain text doesn't scream security to me. So no, unlike a mail server.

It's 2023; mail servers have been using TLS for a very long time.

Re: Email and Git = <3

#203

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?

There are lots of reasons to go plain text only, and stripping links and images from signatures is often in the top 10.

That's fair, the links I put in mine are to my lab and own websites. I am not aware of any better way to share that info other than maybe tiny urls.

Re: Email and Git = <3

#204
post #115

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…

Our project inherited a patchbomb-based workflow from Linux. Many of the individual members have also contributed to gitlab/hub based projects, and appreciated a lot of the automation available, as well as recognizing the lower barrier-to-entry of not having to figure out how to get an SMTP connection. So a few years ago we experimented with allowing "small" patches to be sent via PR on gitlab, and doing the review t…

>Basically, everyone agreed that actually doing the review on gitlab was a lot worse compared to email. There's just so much more flexibility.

Could you elaborate? This is truly shocking to me. Admittedly I have never worked on a project with an email-based workflow, but I can't think of how email would allow comments inline with the patch, which is an incredibly beneficial feature to me.

Re: Email and Git = <3

#205

Earlier quoted context omitted.

I don't know, sending sensitive information over plain text doesn't scream security to me. So no, unlike a mail server.

It's 2023; mail servers have been using TLS for a very long time.

Yes, you can transmit messages via SMTP using TLS, but you don't need any special tools to read the email once it's reached its destination which is the point you seem to be missing. And before you scream PGP, almost nobody uses it.

Re: Email and Git = <3

#206
post #115

Earlier quoted context omitted.

Our project inherited a patchbomb-based workflow from Linux. Many of the individual members have also contributed to gitlab/hub based projects, and appreciated a lot of the automation available, as well as recognizing the lower barrier-to-entry of not having to figure out how to get an SMTP connection. So a few years ago we experimented with allowing "small" patches to be sent via PR on gitlab, and doing the review t…

>Basically, everyone agreed that actually doing the review on gitlab was a lot worse compared to email. There's just so much more flexibility. Could you elaborate? This is truly shocking to me. Admittedly I have never worked on a project with an email-based workflow, but I can't think of how email would allow comments inline with the patch, which is an incredibly beneficial feature to me.

Well yeah, replying in-line to the patch to make comments is definitely a requirement. :-)

You always reply with quotes; and you always reply inline, below the thing you're replying to. Quoted material is typically indicated by '>'.

So for one thing, you can easily trim your reply to just the bits of the patch that you think is important; that makes it easy for anyone reading; you don't have to skip over large parts of the thread.

Then you can also re-arrange what you're replying to, to make it make your reply make more sense.

Furthermore, suppose A replies to the patch and makes comments 1, 2, and 3 (inline in a single email). When person B replies to A's email, they typically also send a single email, perhaps with replies 1' and 3' (trimming out comment 2, which they don't care about). This means if you've read A's mail, you can just read B's mail, and all the "new" comments are collected in one place (with the thing they're replying to).

Contrast the above with gitlab, where A's replies 1, 2, and 3 are spread throughout the patch; and B's replies will also be spread out, meaning you have a kind of discoverability problem to see both 1' and 3'.

And suppose in the course of talking about something you realize this bug may actually be a security issue -- you can remove the list, cc' "security@", and pick up the discussion without having to do any copy & paste. Same goes if you want to make a private comment, or bring something to someone's attention; just reply, remove everyone else, and say "FYI".

I wish I had a really good recent example to show you, but a quick skim of today's threads isn't anything special. :-)

I mean, I was arguing with people online [1] on BBS's in the early 90's, and I was on Usenet back when that was the main social network; so this "reply and comment inline" way of having a discussion is pretty well ingrained for me. But there are people on my team in their early 30's who also took to the email workflow really quickly too.

[1] https://xkcd.com/386/

Re: Email and Git = <3

#207

Earlier quoted context omitted.

It's 2023; mail servers have been using TLS for a very long time.

Yes, you can transmit messages via SMTP using TLS, but you don't need any special tools to read the email once it's reached its destination which is the point you seem to be missing. And before you scream PGP, almost nobody uses it.

But that's exactly the same as anything else; you move git commits that you store locally (either encrypted or not) over an connection that's encrypted in transit (whether SMTP/TLS, HTTP/TLS, or git/SSH) to a remote server that stores the repo/commits (either encrypted or not). None of this is different depending on whether the remote is a mail server or github (or whatever).

Re: Email and Git = <3

#208

Earlier quoted context omitted.

The largest open-source software projects in the world don't use it though, so that tells me there is something lacking.

Maybe so, but my interpretation is that there's personal opposition to change and improvement from people like Linus or TGLX or other greybeards. At least in the linux kernel world. The contribution by email is an antiquated approach and needs to go. Now, knowing the HN crowd this comment will become grey in 3... 2... 1...

What is antiquated about sending patches via email? Have you ever used email to contribute to a project or review a patch?

Re: Email and Git = <3

#209

Earlier quoted context omitted.

It's 2023; mail servers have been using TLS for a very long time.

Yes, you can transmit messages via SMTP using TLS, but you don't need any special tools to read the email once it's reached its destination which is the point you seem to be missing. And before you scream PGP, almost nobody uses it.

TLS secures your message till the endpoint which is a (plaintext) code repo. Why would you want a special tool to read plaintext code? Your argument makes no sense whatsoever.

I’m not sure what you’re getting at here but it sounds more like an irrational hatred of email than something genuinely technical to me.

Re: Email and Git = <3

#210

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's easy to forget the maintainers' side of this.

Yes, most contributors will prefer opening a PR on GitHub as apposed to mailinglists. But imagine instead that you are David Miller, and it's your job to consume the absolute fire hose of patches and messages related to Linux's networking subsystem. Would you rather wade through the hundreds of messages and patches coming in every day using either GitHub PRs and issues or email?

I would choose email for one simple reason: It's easier to script.

Even as a small-time contributor and observer to that space, I couldn't even imagine trying to keep up with everything going on if I couldn't bulk download, filter, tag etc. As a maintainer it would be excruciating.

Post reply on HN