8 ms·

> I've tried several times to make submissions to several e-mail based projects, never with any success. $ git send-email --to=<mailing list> <commit range to

by cyphar 10y ago

> I've tried several times to make submissions to several e-mail based projects, never with any success. $ git send-email --to=<mailing list> <commit range to send> That was hard. > First, you generally have to join a mailing list, which is regularly broken, or requires someone somewhere to manually acknowledge your membership. Most public MLs that accept patches are Cc'd for posterity's sake, and thus generally don't require being a member to post. You will always get Cc'd to discussions (git send-email automatically adds you to the Cc list). > Then, you have to figure out how they want shit formatted, figure out how to generate a diff [...], send an e-mail, find the mailing list shat itself and troubleshoot, try again, etc.... See above. It's one command, or two (git format-patch + send-email) if you want to tweak the email. > (I've been using SVN for 8+ years, git for ~3 years, and have never had to deal with diff files!) I find this hard to believe. You've never hand-edited a diff file with `git add -p` or `git checkout -p` -- or even done a `git diff`, `git show` or `git log -p`? I did all of the above things just today, let alone in the past three years... > If it's somewhere else, or requires another account, there's no way I'm going to spend the effort. I'm going to be honest, as someone who maintains a project hosted on GitHub I don't like it when someone decides they'll "help out" by dropping three lines of code in a patch and disappearing off the face of the earth. If you're not bothered to follow up on your patch review, then you've just inflicted a net negative on the project. > Literally no mailing list host I know of lets you just view a complete topic thread in simple chronological order on ONE PAGE. But chronological order isn't what you want for ML threads. You want to read it as a tree, because that's how people use email... Patch review isn't like a YouTube comment thread.

voltagex_ 10y ago
> $ git send-email --to=<mailing list> <commit range to send> > That was hard. What does this do by default in Windows? In Linux, what if you don't have a local MTA installed/configured? I'd wager most GMail users aren't going to set up Mutt and an application specific password to make it all work.
- gkya 10y ago
  If you don't have a local SMTP setup (MTA is sth else): obtain your patch from your VCS (e.g. git diff revs...), save it to a file, attach to the mail via your mail client.
  - PuercoPop 10y ago
    No need to git diff. Git format-patch does the work for you. Apply the patch with git apply-patch. Less work than sending a PR and the receiver has to do less work to merge locally in a branch should they want to modify something. Github does make it easy for drive by commits for typos an trivial changes like that.
- ajdlinux 10y ago
  You can configure it with SMTP, so it's usable with or without a local MTA. Buuuuuuuuuut, that's still more effort than I'd be comfortable imposing on a new contributor, honestly. Guess why the kernel community keeps pushing away drive-bys?
  - voltagex_ 10y ago
    The Eudyptula Challenge was my first exposure to git-send-email. My first email was rejected due to the attachment being base64 encoded, I think. This is how I know setting up Mutt with GMail is fairly painful. I kinda get why LKML pushes away drive by contributions - if the quality of the patch is low it can cause problems for maintainers and subsystem maintainers. The kernel has stuff like checkpatch.pl to help though. If you're contributing to the kernel you should probably be able to run a Perl script.
  - zeveb 10y ago
    > Guess why the kernel community keeps pushing away drive-bys? Because drive-by contributions to the kernel are likely to be more trouble than they're worth? This is code which will run on every Linux device out there, from thermostats to WiFi access points to individual computers to Google's & Facebook's data centres: it had better come from someone who knows his stuff, inside & out, and it's probably a Good Thing™ if he's not afraid of a command line and email.
fake-name 10y ago
> $ git send-email --to=<mailing list> <commit range to send> > > That was hard. So how the hell does that work? Like, how does git know how to send e-mail? Do I have to stick smtp creds in somewhere? > I find this hard to believe. You've never hand-edited a diff file with `git add -p` or `git checkout -p` -- or even done a `git diff`, `git show` or `git log -p`? I did all of the above things just today, let alone in the past three years... There are many, many ways to interact with git, such as the many, many tools that make it so you don't have to interact with all that shit. tortoisegit is a wonderful tool, and it makes git SO much nicer. > But chronological order isn't what you want for ML threads. You want to read it as a tree, because that's how people use email... Patch review isn't like a YouTube comment thread. Except generally, before I'd interact with a ML, I want to see what the ML is like, and having to click through many, many pages with little content on each is just dumb. Also, you may use e-mail as a tree, but that's you. I use thunderbird, and you can set it to display as a tree, or you can set it to not, and I personally don't. As far as I can tell, 99% of the ML content I've read is basically a shitty, shitty implementation of a simple forum on a much crapper transport.
- orangeshark 10y ago
  You can add send-email configuration in your .gitconfig. Here is an example from the documentation that uses gmail. https://git-scm.com/docs/git-send-email#_use_gmail_as_the_smtp_server https://git-scm.com/docs/git-send-email#_use_gmail_as_the_sm...
- toomuchtodo 10y ago
  > As far as I can tell, 99% of the ML content I've read is basically a shitty, shitty implementation of a simple forum on a much crapper transport. And when Github goes belly up, or whatever the SaaS version control flavor of the month is, mailing lists and their archives will still be there. Simplicity is the ultimate sophistication.
  - orf 10y ago
    And they will still be shit, until it's too hard to find anyone to collaborate on your projects.
Manishearth 10y ago
> That was hard. Yes, it was. I need to set up command-line email locally on my computer. How do I do this on Windows? (or, on Linux, for that matter) How do I do this if behind a proxy? What if port 25 is blocked entirely (i.e. many university networks)? I have been in at least one of these three situations for very long periods of time, each. Of course, I can just format-patch + email, if I don't want to set this up locally. Wait, no, I can't. Gmail replaces tabs with spaces in plaintext emails. Most MLs want plaintext emails. I could use an attachment but not all patch submission processes allow that. So I'm back to needing a client or switching my email provider. Welp. Okay, let's say I managed to get git send-email working locally. Now, how do I send my updated patch after having gotten review? Oh, I see, I need to muck with a Message-ID header. Looking at the first Google result (what most folks trying this will hit) http://studioidefix.com/2014/06/17/replying-to-lkml/ http://studioidefix.com/2014/06/17/replying-to-lkml/ -- it's literally building the email headers from the command line, after some manual copypasting. There may be tools for this, but they're definitely not discoverable. I could sync up my email client via POP or IMAP, but now I have to emails locally, and possibly change how I interact with email. Also, this is another bundle of confusingness. When I first set this up many years ago I synced a bit more than I needed, but was afraid of deleting things because the deletion may be reflected. Getting this set up just right is a whole other world of pain. Nope. Github isn't as easy as those used to it think either, but emailing patches is definitely not easy. I've done a lot of mentoring for folks getting involved in open source. Like I said, it becomes apparent that GitHub isn't as easy as folks think it is. But it's well documented, and still not hard to ramp up on. I've had folks nearly give up on mailing list contributions. > You've never hand-edited a diff file with `git add -p` or `git checkout -p` -- or even done a `git diff`, `git show` or `git log -p`? I People interact with tools differently. GUIs exist. Interacting with diffs is different from interacting with diff files. I've got my `git diff` setup to show a much cleaner colorful diff (except when piped, in which case it shows a diff file). The only time I see normal diff files is when I'm submitting patches to MLs, (or when I'm copying patches across vendored repos; a niche task) the rest of my diff-viewing is with colorful commandline diffs that look quite different. It's easy for me to imagine that folks using GUIs would never directly deal with a diff file. > because that's how people use email... No that's how you use email. Others may not. Reading flattened comment threads is totally fine, even if the underlying review is treelike. Treelike viewing is more suited for viewing updates to a conversation you're otherwise caught up on, but often it's better to view a conversation you haven't seen before in a linear fashion.
netheril96 10y ago
> But chronological order isn't what you want for ML threads. You want to read it as a tree, because that's how people use email... Patch review isn't like a YouTube comment thread. If any of them can display all of the tree on one page, then maybe I won't hate mailing lists so much. I hate clicking back and forth in a swath of emails, each having a little and often irrelevant content, and getting lost in where I am in this "tree".

by cyphar 10y ago

voltagex_ 10y ago

> $ git send-email --to=<mailing list> <commit range to send> > That was hard. What does this do by default in Windows? In Linux, what if you don't have a local MTA installed/configured? I'd wager most GMail users aren't going to set up Mutt and an application specific password to make it all work.

gkya 10y ago
If you don't have a local SMTP setup (MTA is sth else): obtain your patch from your VCS (e.g. git diff revs...), save it to a file, attach to the mail via your mail client.
- PuercoPop 10y ago
  No need to git diff. Git format-patch does the work for you. Apply the patch with git apply-patch. Less work than sending a PR and the receiver has to do less work to merge locally in a branch should they want to modify something. Github does make it easy for drive by commits for typos an trivial changes like that.
ajdlinux 10y ago
You can configure it with SMTP, so it's usable with or without a local MTA. Buuuuuuuuuut, that's still more effort than I'd be comfortable imposing on a new contributor, honestly. Guess why the kernel community keeps pushing away drive-bys?
- voltagex_ 10y ago
  The Eudyptula Challenge was my first exposure to git-send-email. My first email was rejected due to the attachment being base64 encoded, I think. This is how I know setting up Mutt with GMail is fairly painful. I kinda get why LKML pushes away drive by contributions - if the quality of the patch is low it can cause problems for maintainers and subsystem maintainers. The kernel has stuff like checkpatch.pl to help though. If you're contributing to the kernel you should probably be able to run a Perl script.
- zeveb 10y ago
  > Guess why the kernel community keeps pushing away drive-bys? Because drive-by contributions to the kernel are likely to be more trouble than they're worth? This is code which will run on every Linux device out there, from thermostats to WiFi access points to individual computers to Google's & Facebook's data centres: it had better come from someone who knows his stuff, inside & out, and it's probably a Good Thing™ if he's not afraid of a command line and email.

fake-name 10y ago

> $ git send-email --to=<mailing list> <commit range to send> > > That was hard. So how the hell does that work? Like, how does git know how to send e-mail? Do I have to stick smtp creds in somewhere? > I find this hard to believe. You've never hand-edited a diff file with `git add -p` or `git checkout -p` -- or even done a `git diff`, `git show` or `git log -p`? I did all of the above things just today, let alone in the past three years... There are many, many ways to interact with git, such as the many, many tools that make it so you don't have to interact with all that shit. tortoisegit is a wonderful tool, and it makes git SO much nicer. > But chronological order isn't what you want for ML threads. You want to read it as a tree, because that's how people use email... Patch review isn't like a YouTube comment thread. Except generally, before I'd interact with a ML, I want to see what the ML is like, and having to click through many, many pages with little content on each is just dumb. Also, you may use e-mail as a tree, but that's you. I use thunderbird, and you can set it to display as a tree, or you can set it to not, and I personally don't. As far as I can tell, 99% of the ML content I've read is basically a shitty, shitty implementation of a simple forum on a much crapper transport.

orangeshark 10y ago
You can add send-email configuration in your .gitconfig. Here is an example from the documentation that uses gmail. https://git-scm.com/docs/git-send-email#_use_gmail_as_the_smtp_server https://git-scm.com/docs/git-send-email#_use_gmail_as_the_sm...
toomuchtodo 10y ago
> As far as I can tell, 99% of the ML content I've read is basically a shitty, shitty implementation of a simple forum on a much crapper transport. And when Github goes belly up, or whatever the SaaS version control flavor of the month is, mailing lists and their archives will still be there. Simplicity is the ultimate sophistication.
- orf 10y ago
  And they will still be shit, until it's too hard to find anyone to collaborate on your projects.

Manishearth 10y ago

> That was hard. Yes, it was. I need to set up command-line email locally on my computer. How do I do this on Windows? (or, on Linux, for that matter) How do I do this if behind a proxy? What if port 25 is blocked entirely (i.e. many university networks)? I have been in at least one of these three situations for very long periods of time, each. Of course, I can just format-patch + email, if I don't want to set this up locally. Wait, no, I can't. Gmail replaces tabs with spaces in plaintext emails. Most MLs want plaintext emails. I could use an attachment but not all patch submission processes allow that. So I'm back to needing a client or switching my email provider. Welp. Okay, let's say I managed to get git send-email working locally. Now, how do I send my updated patch after having gotten review? Oh, I see, I need to muck with a Message-ID header. Looking at the first Google result (what most folks trying this will hit) http://studioidefix.com/2014/06/17/replying-to-lkml/ http://studioidefix.com/2014/06/17/replying-to-lkml/ -- it's literally building the email headers from the command line, after some manual copypasting. There may be tools for this, but they're definitely not discoverable. I could sync up my email client via POP or IMAP, but now I have to emails locally, and possibly change how I interact with email. Also, this is another bundle of confusingness. When I first set this up many years ago I synced a bit more than I needed, but was afraid of deleting things because the deletion may be reflected. Getting this set up just right is a whole other world of pain. Nope. Github isn't as easy as those used to it think either, but emailing patches is definitely not easy. I've done a lot of mentoring for folks getting involved in open source. Like I said, it becomes apparent that GitHub isn't as easy as folks think it is. But it's well documented, and still not hard to ramp up on. I've had folks nearly give up on mailing list contributions. > You've never hand-edited a diff file with `git add -p` or `git checkout -p` -- or even done a `git diff`, `git show` or `git log -p`? I People interact with tools differently. GUIs exist. Interacting with diffs is different from interacting with diff files. I've got my `git diff` setup to show a much cleaner colorful diff (except when piped, in which case it shows a diff file). The only time I see normal diff files is when I'm submitting patches to MLs, (or when I'm copying patches across vendored repos; a niche task) the rest of my diff-viewing is with colorful commandline diffs that look quite different. It's easy for me to imagine that folks using GUIs would never directly deal with a diff file. > because that's how people use email... No that's how you use email. Others may not. Reading flattened comment threads is totally fine, even if the underlying review is treelike. Treelike viewing is more suited for viewing updates to a conversation you're otherwise caught up on, but often it's better to view a conversation you haven't seen before in a linear fashion.

netheril96 10y ago

> But chronological order isn't what you want for ML threads. You want to read it as a tree, because that's how people use email... Patch review isn't like a YouTube comment thread. If any of them can display all of the tree on one page, then maybe I won't hate mailing lists so much. I hate clicking back and forth in a swath of emails, each having a little and often irrelevant content, and getting lost in where I am in this "tree".