Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Email and Git = <3

git-send-email.io

Post reply on HN
Print view View original

121–130 of 265 posts

Re: Email and Git = <3

#121

Post by fodkodrasz »

djha-skin wrote: post #105
BaculumMeumEst wrote: post #21

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.

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

Re: Email and Git = <3

#123

Post by emersion »

ligurio wrote: post #74

I appreciate the effort here, but in the proposed workflow are missed steps with subscribing to a mailing list. Without proper subscriptions and confirming subscription, your mails with patches will go to trash.

That's not true in general. Many mailing lists accept emails from unsubscribed users, some moderate them (requiring moderator approval for the first post), but I don't know of any which outright rejects such emails.

Re: Email and Git = <3

#124

Post by gwd »

webdevver wrote: post #35

I wish I could "preview" sending my patch to mailing lists. I've considered the idea of having a localhost mailing list for the sole purpose of sending it there just to make sure that i've got everything setup right, but haven't gotten around to doing it yet.

    git send-email --dry-run
will show you the mail headers it would have generated (including subject lines, To: and Cc: fields).

    git format-patch -o
will create a separate mail-like file for each patch in . Finally,

    git format-patch --stdout  > foo.mbox
will (I think) generate something which something capable of reading mbox'es should be able to read. (The latter I may be remembering incorrectly, but worth giving a try.)

Re: Email and Git = <3

#125

Post by andris9 »

trws wrote: post #96
oefrha wrote: post #61

Earlier quoted context omitted.

That uses app specific passwords, and with Google Workspace, the administrator can completely turn off these “less secure apps”. Pretty sure Office 365 has the same.

Sadly you’re right. Microsoft has brainwashed many IT departments into forcing oauth on everything, no app specific passwords, no regular passwords, nothing else. Thankfully they do support this on imap and smtp, but you have to have something that can handle it. I use a modified version of isync with the sasl plugin to fetch mail, and a python smtp sender that supports the oauth flow along with a set of scripts for…

Multiple enterprise customers use my software (https://emailengine.app) because it can proxy OAuth2-enabled IMAP/SMTP connections as regular password-based sessions. Turns out there are a lot of legacy, like all kinds of cron scripts, that want to connect to some IMAP account to check and do something. It all breaks down once the organisation enforces OAuth for their email. So, personally, I don't like it at all, but as a software developer, I'm really happy about it. Helps with my sales effort :P

Re: Email and Git = <3

#126

Post by gwd »

One thing this is missing is cover letters for longer series. Last time I checked that was the biggest pain: the fact that there's no real convenient way to store the cover letters; `git send-email --cover` will expect you to compose a new one every time.

Re: Email and Git = <3

#127

Post by BaculumMeumEst »

howenterprisey wrote: post #84
ploum wrote: post #31

Earlier quoted context omitted.

Organizations that insists on using a web interface and ever-changing click workflows not only drive away a significant number of very knowledgeable contributors, but they also form a weirdly irrational culture that fetishizes needlessly graphical content, marketing and fake-usability detrimental to learnability and integration with each user workflow.

What on earth is "fake-usability"? It's more usable, just admit it.

Fake-usability is when 97/100 software developers find something more usable, but it's fake because I've invested a lot of time doing it a different way and gotten used to it.

Re: Email and Git = <3

#128

Post by zanecodes »

IshKebab wrote: post #113
diggan wrote: post #90

Earlier quoted context omitted.

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.

How is that harder than signing up to Github?

I only have to sign up to Github once, not once per project.

Re: Email and Git = <3

#129

Post by IshKebab »

brettermeier wrote: post #111
severus_snape wrote: post #69

Earlier quoted context omitted.

You don't need to subscribe. You are in CC when people want you to be notified, otherwise there are web interfaces you can browse. See https://lists.gnu.org/archive/html/guix-devel/ for example. On each message there is a button: "reply via email to [...]".

Damn, this is ugly and confusing, I mean, look at the threads XD! I'm glad I must not use this shit.

Shh now. A basic interface that took 5 minutes to make in 1995 is good enough for all eternity. No need to change it.

Re: Email and Git = <3

#130

Post by rpdillon »

severus_snape wrote: post #97
emptysongglass wrote: post #95

Earlier quoted context omitted.

This interface is awful. I wish GNU would make more of an effort to be easy to contribute to.

I usually know, when the interface is not too shiny, that the content might be good. It's the same with HN. And those interfaces are still very easy to understand and use. That being said, there is certainly room for improvement.

There's something to this idea, I think. The less polished a tool is, the more I'm inclined to think it was built by the community for community use. There's so much talk about enshitification, and I'm struggling to recall when a tool with a less-than-polished interface had that problem.

The example that springs to mind is spamgourmet, which has a FAQ about why they don't redesign their site. I've used the service for about 20 years, and while there is a bit of a gatekeeping vibe to it, there is also a good reason: they have very few resources for support, and want to attract a certain crowd to minimize the support burden. It seems it's been working for a couple of decades, at least.

> Q. Couldn't you make the whole thing a lot easier to understand by redesigning your site and providing instructions in a more clear way?

> A. Probably. Frankly, we're trying to build a user base of people like you, who probably have some familiarity with the way email works and who are willing to read FAQ's. This is to keep our support burden to a minimum (this is a non-commercial service). So far, the approach has worked well -- just about all our users hit the ground running with no need for support, and it's our belief that those users who would require support generally don't sign up in the first place, perhaps because of the geeky presentation of the site. That's not to say we don't provide support where it's needed -- after skimming this FAQ, please don't hesitate to write if you have a question or believe there's a bug.

https://www.spamgourmet.com/index.pl?printpage=faq.html

I tend to actively seek out projects like this, since I don't mind the blow to usability, and very much appreciate that they provide the service and don't pepper me with annoucements about their new improvements or their changes to their pricing structure.

Post reply on HN