Live data from Hacker News

Email and Git = <3

git-send-email.io

221–230 of 265 posts

Re: Email and Git = <3

#221
post #100

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.

You mean

- cloning the repo in github to your own fork

- cloning your fork locally

- pushing to your local fork after you've made your change

- opening a PR

Which is the expected flow for any project you're not already part of, ie all of them.

The email workflow:

- send an email

I can't fathom how you can say the email workflow is more complicated.

Re: Email and Git = <3

#222
post #54

Earlier quoted context omitted.

It really kills the fun when contributing to any FOSS project that fetishizes these tools and holds them up as some kind of proof of hacker cred. I've given up. The latency is too high and the tools are terrible.

“Want to contribute? Subscribe to our mailing list that sends a hundred emails a day.” Nope.

"Want to contribute ? Open yet another account" Nope

"Want to contribute ? Give Microsoft even more power" Nope

Re: Email and Git = <3

#223
post #32

Earlier quoted context omitted.

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…

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 stacko…

You were a github consumer.

You are now a git user.

Re: Email and Git = <3

#224
post #179

I've used email-based workflow for a few contributions I've made. 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 sam…

You have some points, for some I do think it isn't as bad as you write. FWIW, some comments inline. > - 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. You can use tools like public-inbox or lei, the former is hosted for bigger projects on https://lore.kernel.org/ If you're interested, see…

I read this, and it's like, sure, you could do all of this shit. But you could also just choose a better system outright.

Re: Email and Git = <3

#225
post #210

Earlier quoted context omitted.

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 issu…

Github has an api for this…

And once you've used that API to download and tag everything, what tools do you use to interactively view the results, run search queries, apply patches to local trees etc?

If your on-disk format is an Mbox or a Maildir, you can use tools like notmuch and its emacs integration to do it.

Now don't get me wrong; I love GitHub. I host all my projects there, and I prefer PRs+issues to mailinglists in almost all cases. But for massive projects like Linux, a mailinglist (and associated tooling) scales better, in my opinion.

Re: Email and Git = <3

#226
post #206

Earlier quoted context omitted.

>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…

Thanks for taking the time to respond. I'm surprised to find that there are people out there who think endlessly nested >'s are a good solution, but it's always nice to have one's world view expanded :)

Re: Email and Git = <3

#227
post #206

Earlier quoted context omitted.

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…

Thanks for taking the time to respond. I'm surprised to find that there are people out there who think endlessly nested >'s are a good solution, but it's always nice to have one's world view expanded :)

For one thing, most GUI mail readers will automatically convert the `>` into nested block quotes.

For another, it's not common to see more than 2 levels of `>` (your text, the thing you're replying to, and the thing they're replying to); and yes, when it gets past 4 it begins to get really unreadable, so my gut feel is that it's extremely rare (although I wouldn't be certain without doing some sort of data mining).

As I said, the main advantage of using email is the flexibility you have in editing the response; part of learning how to use the review workflow effectively is learning how to present the context; which means trimming the replies to balance information and readability.

Re: Email and Git = <3

#228
post #216
post #200

Earlier quoted context omitted.

> Configuring git send-email is trivial The linked article is literally a multi-step process of arcane terminal commands that differ by operating system. You may think it's easy, but it's definitionally not trivial.

The thing that differs by OS is the installation of Git.

Is this installing git?

    sudo -H cpan Net::SMTP::SSL IO::Socket::SSL

Re: Email and Git = <3

#229
Please do not contribute to this silly archaic practice. It was once not silly. It is now archaic, and it is silly to do it now that we have vastly superior tools.

Re: Email and Git = <3

#230
post #179

I've used email-based workflow for a few contributions I've made. 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 sam…

You have some points, for some I do think it isn't as bad as you write. FWIW, some comments inline. > - 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. You can use tools like public-inbox or lei, the former is hosted for bigger projects on https://lore.kernel.org/ If you're interested, see…

The amount of "gotchas" in this process and the tooling required just to use git + email seems insane to me. If it works for you, great, but I don't expect a new hire (experienced or not) to pickup this flow and run with it.
Post reply on HN