Live data from Hacker News

Email and Git = <3

git-send-email.io

161–170 of 265 posts

Re: Email and Git = <3

#161

Earlier quoted context omitted.

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

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

Re: Email and Git = <3

#162
post #118

Earlier quoted context omitted.

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

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.

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

Re: Email and Git = <3

#163
post #38
post #11

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

Re: Email and Git = <3

#164

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…

> 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 needlessly painful process and is incapable of improvement

You could say the same of GitHub. Why do I need an account on your lil site just to get a patch accepted?

Re: Email and Git = <3

#165
post #76
post #66

Earlier quoted context omitted.

You don't have to subscribe to send a patch to a mailing list.

I have more than once subscribed just to report a bug or send a patch because the mailing list rejects emails from non-subscribers. Edit: Btw, yes I have done the periodically-check-archive thing in the past, thank you. Hated it. Also missed a response once because I forgot to check and replier didn't CC. I realized like a month later.

It is unfortunate that there are poorly-managed projects with poorly-managed mailing lists (just like there are poorly-managed projects on Github), but sourcehut at least requires a properly-managed mailing list, and I think you should evaluate this workflow on that standard. Tell poorly-managed projects to move to sourcehut, if you want to fix this issue.

Re: Email and Git = <3

#166
post #103

Earlier quoted context omitted.

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.

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

If you decide to expand your horizons, take a look not only at the venerable CVS but also at things like perforce, fossil, and pijul.

Re: Email and Git = <3

#167
post #42

Earlier quoted context omitted.

“needlessly graphical” requires a citation when it’s clear that if you use a web GUI for this you address a market of potential contributors that is three to six orders of magnitude larger. srht is really designed for (and thus only really useful for) lone wolf developers who collaborate rarely, if ever, and with a very small number of collaborators who collaborate infrequently. It is not built for large teams with c…

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.

Re: Email and Git = <3

#168

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

They say that scientific discovery advanced one death at a time. I imagine this same theory applies to kernel development tooling.

I understand not changing for change sake. The kernel is at this time not "this gen" developer friendly.

Re: Email and Git = <3

#169

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…

> Organizations that insist on using workflows like git send-mail and mailing lists not only drive away a significant number of potential contributor

Often that's a bonus if not the whole point to begin with. The higher the barrier to entry the less noise you need to filter through.

It only feels annoying to you because you're not used to it.

Re: Email and Git = <3

#170

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!

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'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.
Post reply on HN