5 ms·
> 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
by 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.
- u801e 10y ago> 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) All of those questions are answered in the man page for git send-email. You can specify them via a command line option when invoking that command, or just add that information to the git config file. > Wait, no, I can't. Gmail replaces tabs with spaces in plaintext emails. Is that done by the Gmail web client or is it something done by their SMTP server? > Oh, I see, I need to muck with a Message-ID header. One thing that I think would be an improvement to git format-patch and git send-email is having it default to setting the Message-Id header in the email it generates rather than relying on the SMTP server to generate it. > but often it's better to view a conversation you haven't seen before in a linear fashion. How do you deal with the case when multiple discussion threads are interleaved with each other? Is it easy to find the email that was partially quoted the message you're viewing?
- Manishearth 10y ago> All of those questions are answered in the man page for git send-email. You can specify them via a command line option when invoking that command, or just add that information to the git config file. Many, many pages below in the configuration section. Yes, on its own that's not too big a deal (you can always google the setup, though for me it's the fourth result on google that is not the man page itself). But this stacks up with the rest of the issues -- with send-email it's tricky to respond to existing review threads with new patches. Clients fix that, but they have a whole host of other issues. > Is that done by the Gmail web client or is it something done by their SMTP server? The web client. Whether or not SMTP does this isn't the point here -- I brought up the web client as an alternative to using SMTP, because SMTP is not an option for many, and even if it is, one really shouldn't have to set up an email client and potentially change their email workflow to contribute patches. > One thing that I think would be an improvement to git format-patch and git send-email is having it default to setting the Message-Id header in the email it generates rather than relying on the SMTP server to generate it. That doesn't make sense, it doesn't know what message id to set. It needs to hook in to a mail client to know that. > How do you deal with the case when multiple discussion threads are interleaved with each other? Is it easy to find the email that was partially quoted the message you're viewing? I meant chronological view for a given thread. You still need fully threaded view, but comprehending an entire thread in non-inlined fully-threaded view is really annoying. Inlining the emails or using some JS for expand/collapse can help, but as it stands most if not all web interfaces for MLs are terrible.