3 ms·

> 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

• 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.
  • u801e 10y ago
    >> 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 If I happen to be using a mail client that doesn't modify the content of the patch and configure it to use Gmail's SMTP server, then it certainly renders that point moot. On the other hand, if it was the SMTP server then it would not be possible to send patches in that fashion regardless of what MUA was used (and would be a bigger problem in terms of contributing to projects that require inline patch submission via email). >> 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 could use the value like <commit-sha1>@localdomain. Basically the message-id value should be a relatively unique value. > It needs to hook in to a mail client to know that. I think we may not be on the same page here. I was referring to the Message-Id header of the message itself (when it's written to disk by git format-patch), not the value of the In-Reply-To header or the last value in the References header. So if git format-patch set that header when generating the message (rather than relying on the SMTP server to set that header), then you could easily have it refer to the file generated by the previous invocation by name, via a command option, to retrieve the message-id value and use it to populate the In-Reply-To and References headers (instead of having to retrieve the message from some remote server and copying its message-id value to specify as a command line option). > but as it stands most if not all web interfaces for MLs are terrible. This is why I prefer having an NNTP gateway (like gmane) to browse mailing lists using my locally installed MUA (or newsreader).
    • Manishearth 10y ago
      > If I happen to be using a mail client that doesn't modify the content of the patch and configure it to use Gmail's SMTP server, then it certainly renders that point moot. The whole point was that I was discussing an alternative to mail clients, however. If this was an issue with clients I would have brought it up with clients. > It could use the value like <commit-sha1>@localdomain. Basically the message-id value should be a relatively unique value. git commit --amend breaks this. You need to come up with some stable scheme here. Branch name could work. Ties you to a specific contribution model, though. So does github; but in a more overt way, this could lead to hidden bugs occurring. I usually don't use a branch when contributing to GDB (which uses an ML), for example, I just use a detached head. > I think we may not be on the same page here. I was referring to the Message-Id header of the message itself (when it's written to disk by git format-patch), not the value of the In-Reply-To header or the last value in the References header. Yeah, but that's tricky to autoset in a stable way, too, like I say above. > This is why I prefer having an NNTP gateway (like gmane) to browse mailing lists using my locally installed MUA (or newsreader). Right, but this just increases the barrier to easy participation