5 ms·

> 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

> 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

u801e 10y ago
> 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. Granted, but I think that if projects require submitting patches via email, then using a local mail client makes it much easier to do so. I don't see having to install and configure an MUA any more of a barrier to contributing than it is to install a web browser to use Github to contribute to other projects that expect pull requests. >> 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. No, it doesn't. git am doesn't make any use of the message-id header when applying the patch to your working copy. The commit in your local repository will have a different sha1 compared to the corresponding commit the patch author has (or any other reviewer who has applied that patch to their own working copy for that matter). Basically the steps would be: 1. Generate a patch series using git format-patch 2. Use git-send-email to send the patches to the mailing list. 3. Get reviews 4. Address comments 5. Use git format-patch to generate a new patch series for re-roll with a command line parameter that refers to the file containing the cover letter for the original patch series. The command line parameter that I mention would be able to retrieve the value of the message-id that was generated by the first invocation of git format-patch and then set the values of the In-Reply-To and References headers in the new cover letter message without you having to manually copy it from your original message when viewing it in your MUA (or web browser). > Yeah, but that's tricky to autoset in a stable way, too, like I say above. The sha1 of the commit should be unique enough. Assuming the SMTP server doesn't override what was set by the client, then it should work without any issues. I have tested this with one commercial SMTP server by manually setting the Message-Id header in a telnet session and did see it unaltered in the message I received. I still need to run this test with other SMTP servers to see if I get the same result. >> 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 I disagree. It's not fundamentally harder to use a MUA, news reader, or IRC client than it is to use a web browser.
- Manishearth 10y ago
  > I don't see having to install and configure an MUA any more of a barrier to contributing than it is to install a web browser to use Github to contribute to other projects that expect pull requests. Almost everyone has a web browser installed. Not everyone has a MUA installed. > 5. Use git format-patch to generate a new patch series for re-roll with a command line parameter that refers to the file containing the cover letter for the original patch series. This was the step I missed, thanks. This could work. You now need to keep your patches around, but it could work. > The sha1 of the commit should be unique enough. I meant stable across local changes to the commit. I didn't realize you were serializing this commit hash to some file and fetching it from the file later. > I disagree. It's not fundamentally harder to use a MUA, news reader, or IRC client than it is to use a web browser. I believe more people have a web browser set up than they do a MUA. You cannot browse the web effectively without a web browser (I mean, you can use lynx, but the modern web is not well suited for that), and this is pretty necessary these days. You can use email effectively without a local email client, however. It's not just that the MUA is harder to set up, it's that you're asking people to effectively change their entire workflow for interacting with email just so that they can contribute. And yes, MUAs are harder to set up. Refer to aforementioned points about blocked ports, confusing IMAP/POP3 deletion semantics (I don't want to accidentally delete all my email!), proxies, etc.
  - u801e 10y ago
    > Almost everyone has a web browser installed. Not everyone has a MUA installed. It shouldn't be an issue to install one. A somewhat related example I recently came across was when I had to install Google chrome to use a feature of Slack that wasn't supported in Firefox. To get around that issue, I installed chrome. If I had to, I would have also had to set up the necessary proxy configuration for that browser to work (though that wasn't the actually the case). Similarly, if one wants to contribute to a project that requires emailed patch files, then part of the process should be installing and setting up a MUA if the web based front-end doesn't work properly. > This was the step I missed, thanks. This could work. You now need to keep your patches around, but it could work. I think it's easier than having to retrieve the original message via IMAP, POP, or HTTP and copying its message-id value :) > I meant stable across local changes to the commit. I didn't realize you were serializing this commit hash to some file and fetching it from the file later. Typically, when contributors do a re-roll of a patch set, they effectively either use git commit --amend or git rebase to update the commits in the branch they're working on. The updated patchset is sent to the mailing list and pulled down by reviewers and applied to their working tree (which results in a commit with the same change, but a different SHA1). This is unlike the case where one runs git fetch or git pull and pulls down the commits and gets the commits with the same SHA1 applied to their local copy. In other words, the SHA1 value isn't that important other than to serve as a unique value of the message-id header. > You can use email effectively without a local email client, however. I use both web based clients (hotmail, gmail) and a locally installed MUA (thunderbird). I can say that I have a better user experience with the MUA compared to the web based front ends. For the purposes of patch submission, reviewing, etc, I think that web based clients are really not sufficient due to the lack of threading (as I would see it in a traditional email client). > it's that you're asking people to effectively change their entire workflow for interacting with email just so that they can contribute. There are a number of steps one has to take to contribute to a project. Reading documentation, installing the software, documenting the bug they're proposing to fix, discussing the approach with project maintainers, implementing the change, testing the change, submitting the fix, responding to reviews, etc. Just submitting the patch is a small part of the overall process. For example, a contributer would have to set up the development environment such that they can run the tests that come with the project. That in itself could be a bit more work than figuring out how to use git send-email to submit the patches. > MUAs are harder to set up. Refer to aforementioned points about blocked ports, confusing IMAP/POP3 deletion semantics It's easy enough to see whether or not ports are blocked by attempting to connect to the SMTP, POP/IMAP servers. As for the "confusing [...] deletion semantics", I have never encountered an issue where I accidentally deleted all my email in the last 22 some years of using email while using my local MUA.

u801e 10y ago

> 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. Granted, but I think that if projects require submitting patches via email, then using a local mail client makes it much easier to do so. I don't see having to install and configure an MUA any more of a barrier to contributing than it is to install a web browser to use Github to contribute to other projects that expect pull requests. >> 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. No, it doesn't. git am doesn't make any use of the message-id header when applying the patch to your working copy. The commit in your local repository will have a different sha1 compared to the corresponding commit the patch author has (or any other reviewer who has applied that patch to their own working copy for that matter). Basically the steps would be: 1. Generate a patch series using git format-patch 2. Use git-send-email to send the patches to the mailing list. 3. Get reviews 4. Address comments 5. Use git format-patch to generate a new patch series for re-roll with a command line parameter that refers to the file containing the cover letter for the original patch series. The command line parameter that I mention would be able to retrieve the value of the message-id that was generated by the first invocation of git format-patch and then set the values of the In-Reply-To and References headers in the new cover letter message without you having to manually copy it from your original message when viewing it in your MUA (or web browser). > Yeah, but that's tricky to autoset in a stable way, too, like I say above. The sha1 of the commit should be unique enough. Assuming the SMTP server doesn't override what was set by the client, then it should work without any issues. I have tested this with one commercial SMTP server by manually setting the Message-Id header in a telnet session and did see it unaltered in the message I received. I still need to run this test with other SMTP servers to see if I get the same result. >> 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 I disagree. It's not fundamentally harder to use a MUA, news reader, or IRC client than it is to use a web browser.

Manishearth 10y ago
> I don't see having to install and configure an MUA any more of a barrier to contributing than it is to install a web browser to use Github to contribute to other projects that expect pull requests. Almost everyone has a web browser installed. Not everyone has a MUA installed. > 5. Use git format-patch to generate a new patch series for re-roll with a command line parameter that refers to the file containing the cover letter for the original patch series. This was the step I missed, thanks. This could work. You now need to keep your patches around, but it could work. > The sha1 of the commit should be unique enough. I meant stable across local changes to the commit. I didn't realize you were serializing this commit hash to some file and fetching it from the file later. > I disagree. It's not fundamentally harder to use a MUA, news reader, or IRC client than it is to use a web browser. I believe more people have a web browser set up than they do a MUA. You cannot browse the web effectively without a web browser (I mean, you can use lynx, but the modern web is not well suited for that), and this is pretty necessary these days. You can use email effectively without a local email client, however. It's not just that the MUA is harder to set up, it's that you're asking people to effectively change their entire workflow for interacting with email just so that they can contribute. And yes, MUAs are harder to set up. Refer to aforementioned points about blocked ports, confusing IMAP/POP3 deletion semantics (I don't want to accidentally delete all my email!), proxies, etc.
- u801e 10y ago
  > Almost everyone has a web browser installed. Not everyone has a MUA installed. It shouldn't be an issue to install one. A somewhat related example I recently came across was when I had to install Google chrome to use a feature of Slack that wasn't supported in Firefox. To get around that issue, I installed chrome. If I had to, I would have also had to set up the necessary proxy configuration for that browser to work (though that wasn't the actually the case). Similarly, if one wants to contribute to a project that requires emailed patch files, then part of the process should be installing and setting up a MUA if the web based front-end doesn't work properly. > This was the step I missed, thanks. This could work. You now need to keep your patches around, but it could work. I think it's easier than having to retrieve the original message via IMAP, POP, or HTTP and copying its message-id value :) > I meant stable across local changes to the commit. I didn't realize you were serializing this commit hash to some file and fetching it from the file later. Typically, when contributors do a re-roll of a patch set, they effectively either use git commit --amend or git rebase to update the commits in the branch they're working on. The updated patchset is sent to the mailing list and pulled down by reviewers and applied to their working tree (which results in a commit with the same change, but a different SHA1). This is unlike the case where one runs git fetch or git pull and pulls down the commits and gets the commits with the same SHA1 applied to their local copy. In other words, the SHA1 value isn't that important other than to serve as a unique value of the message-id header. > You can use email effectively without a local email client, however. I use both web based clients (hotmail, gmail) and a locally installed MUA (thunderbird). I can say that I have a better user experience with the MUA compared to the web based front ends. For the purposes of patch submission, reviewing, etc, I think that web based clients are really not sufficient due to the lack of threading (as I would see it in a traditional email client). > it's that you're asking people to effectively change their entire workflow for interacting with email just so that they can contribute. There are a number of steps one has to take to contribute to a project. Reading documentation, installing the software, documenting the bug they're proposing to fix, discussing the approach with project maintainers, implementing the change, testing the change, submitting the fix, responding to reviews, etc. Just submitting the patch is a small part of the overall process. For example, a contributer would have to set up the development environment such that they can run the tests that come with the project. That in itself could be a bit more work than figuring out how to use git send-email to submit the patches. > MUAs are harder to set up. Refer to aforementioned points about blocked ports, confusing IMAP/POP3 deletion semantics It's easy enough to see whether or not ports are blocked by attempting to connect to the SMTP, POP/IMAP servers. As for the "confusing [...] deletion semantics", I have never encountered an issue where I accidentally deleted all my email in the last 22 some years of using email while using my local MUA.