Live data from Hacker News

Email and Git = <3

git-send-email.io

141–150 of 265 posts

Re: Email and Git = <3

#141

> Warning! Some people think that they can get away with sending patches through some means other than git send-email, but you can't. Could someone elaborate on this? Obviously it’s not intended, but is there anything wrong, from a technical standpoint, with using `git format-patch`, zipping the result, attaching it to an email using a GUI email client, and sending it to a maintainer who unzips and runs `git am`?

Zipping the patch kind of works around the issue but introduces probable workflow-incompatibilities, maintainers expect the patch itself in the email, not a compressed archive of the patch.

Re sending patches in email clients without using send-email, some clients (famously Outlook) try to be "helpful" and for example remove blank lines (double or single, don't remember) for example and will corrupt the patch in the process.

Re: Email and Git = <3

#142
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 think you meant “how is signing up for GitHub harder than that?”

Re: Email and Git = <3

#143

Earlier quoted context omitted.

your parens enclose the most unneeded addendum i have ever seen

That's surely hyperbole. You can just say "This is unnecessary" and it achieves the same purpose. Maximalist comments like this tend to amplify the tension in these sorts of discussions.

yes it is hyperbole

Re: Email and Git = <3

#144

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.

[deleted]

Re: Email and Git = <3

#145
post #72

Earlier quoted context omitted.

> Configuring git send-email is trivial, definitively faster than creating an account at some web UI from a "source forge" . You forgot that mailing list requires subscription and in some cases it could be a tricky. Without proper subscriptions and confirming subscription, your mails with patches will go to trash.

There is usually no need to subscribe.

This. You just To: the mailing-list and depending on the project CC: the maintainers.

No subscribing needed. Standard policy on all mailing lists is to reply-to-all so you'll get always CC'ed on replies. This also makes it very easy to pull in more people into a discussion, even across different projects.

Re: Email and Git = <3

#146

Earlier quoted context omitted.

Hard agree! I think the success of Github's PR system over Git + email workflows has proved itself quite well through sheer adoption numbers.

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

Re: Email and Git = <3

#147
post #73
post #66

Earlier quoted context omitted.

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

Presumably you'd be interested in any feedback, and not everyone CCs the original author in their reply.

Reply-to-all is the standard policy on most mailing lists. Especially on -devel lists since you'll pull in (CC:) people outside of the mailing list (cross-project) into discussions from time to time.

Re: Email and Git = <3

#148

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.

No, it drives away people who don't want to develop in vim or emacs and prefer to use modern tools instead.

Re: Email and Git = <3

#149
post #73

Earlier quoted context omitted.

Presumably you'd be interested in any feedback, and not everyone CCs the original author in their reply.

Reply-to-all is the standard policy on most mailing lists. Especially on -devel lists since you'll pull in (CC:) people outside of the mailing list (cross-project) into discussions from time to time.

I know more than one occasion where that has gotten an angry reply.

It's also not the default in many clients. It's tedious and error-prone.

Re: Email and Git = <3

#150
post #103

Earlier quoted context omitted.

Indeed they do. There's impressively many heavy-duty projects that use it. A great many OSes. There's certainly something to it! :)

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 :)
Post reply on HN