6 ms·

> patches in emails Cringe.

by voodootrucker 6y ago

ornornor 6y ago
?
bjoli 6y ago
Give me a better non-locked-in experience than a mailing list, gnus/mu4e and magit and I am happy to try it out.
- williamdclt 6y ago
  Your argument stands, but this non-locked-in experience is so bad it locks most people out. I've done it, I did contribute to Git, and the experience was horrible. The amount of time spent on the mailing part was far far greater and confusing than the amount of time writing code (one of the patch was just a wording change actually). And I don't see how using github locks you in, switching to gitlab, bitbucket or whatever is dead simple. Honestly, the only 2 arguments I see for this process are "that's what we always did and we don't want to make the effort to switch" and "having a high barrier keeps newbies out and we don't consider it a bad thing"
  - u801e 6y ago
    > so bad it locks most people out. Could you specifically describe why it locks most people out? > I did contribute to Git, and the experience was horrible. What was bad about it? > The amount of time spent on the mailing part was far far greater and confusing than the amount of time writing code From what I've read on the mailing list, a lot of the time was spent discussing the patch or patch series in general. That's what should be done when submitting changes. What was confusing about it? > And I don't see how using github locks you in, switching to gitlab, bitbucket or whatever is dead simple. Well, with issues, metadata in PR discussoins, etc, migrating does take a bit of effort. What's simple about it? On the other hand, I could connect via NNTP to public inbox (or possibly gmane) and download 15+ years of patch series discussions in a couple of minutes.
    - Avamander 6y ago
      The single conclusive answer to your questions is "everything", absolutely every single component in that process is obsolete, cumbersome, finicky and convoluted. What's confusing about that description?
      - u801e 6y ago
        > that process is obsolete, cumbersome, finicky and convoluted. It just sounds like you don't like the process since you apparently aren't able to express a specific issue with it. Here's what I don't like about Github 1. You need to set up an account on there (I already have an email account) 2. You need to fork a repo rather than just simply cloning it. This means you have to go through a rather convoluted process to keep your fork up to date with the original repo. That either involves setting up another origin pointing to the original repo and then pushing up those changes to your forked repo (and taking into account any branches you updated). Or you have to delete the forked repo, fork it again and then have to somehow resolve possible conflicts when running git pull. 3. It's not possible to comment on a commit message itself This means that I need to comment on the first line of the diff for that commit or I have to edit the url to navigate to the commit itself and then type stuff into a comment box at the very bottom of the diff. Then that comment doesn't show up with any context other than saying "github-user commented on abcdef1". And those comments disappear when someone force pushes to the branch to update the commit. If the comment is associated with the first line of the diff for that commit, it either is collapsed or not depending on whether the line changed. I still have to go to the commit view to check whether the updated commit message addresses my comment. 4. It collapses comment threads when the line of code changes regardless of whether the change pertains to the original comment. This means I have to scroll from the top of the conversation view page and search for collapsed comment threads to find the comment I made, then go to the diff view to compare that line with what's in the current diff to determine whether the change actually addresses a comment I made 5. It's not easy to jump between different revisions of the branch over several force pushes in a way that makes it easy for me to see what changed on a per commit basis 6. It doesn't provide a way to distinguish different subthreads of conversations on the same block of code 7. It requires far more scrolling in the conversation view when there are a lot of comments on a pull request As for email, all I need to do is 1. Run a few git config commands to set up git to send email using my existing email account (this is a one type step) git config --global --add sendEmail.smtpServer "your.server" git config --global --add sendEmail.smtpServerPort 587 git config --global --add sendEmail.smtpEncryption tls git config --global --add sendEmail.smtpUser "your.email.username" 2. Clone their repo, check out the appropriate branch, make your own branch and do your work If the upstream repo is updated while you do you work, you can simply run git fetch and rebase your local branch on top of the updated branch, which is a lot less convoluted compared to what you have to do to keep a Github forked repo up to date. 3. Create your patch files with cover letter git format-patch --to email.list.address --cover-letter base-branch 4. Edit the cover letter file and update the subject and body to include your patch series description (which isn't much different than composing the PR description on Github) 5. Run git-send-email to send your patch series to the email list git-send-email *.patch 6. Check your email for replies, engage in addition discussion, etc (which is better than having to scroll through a large diff to find every comment) 7. Update your code, rebase 8. Run git format-patch the same way but add -v2 to indicate a reroll 9. Run git-send-email and reference the message-id of the original cover letter In terms of engaging in discussion over email, one can reply inline and comment on any part of the cover letter, commit message, line in the patch etc. One can save the emails from multiple patch series, run git am to apply them in different branches locally and run git diff or git range-diff to check what's changed. That's not possible in Github if someone force pushes to the branch because there's no longer a remote branch to fetch to allow for a comparison. In any case, I would certainly be interested to read your specific complaints about the email based process instead of just a dismissive reply.

> patches in emails Cringe.

ornornor 6y ago

bjoli 6y ago

Give me a better non-locked-in experience than a mailing list, gnus/mu4e and magit and I am happy to try it out.

williamdclt 6y ago
Your argument stands, but this non-locked-in experience is so bad it locks most people out. I've done it, I did contribute to Git, and the experience was horrible. The amount of time spent on the mailing part was far far greater and confusing than the amount of time writing code (one of the patch was just a wording change actually). And I don't see how using github locks you in, switching to gitlab, bitbucket or whatever is dead simple. Honestly, the only 2 arguments I see for this process are "that's what we always did and we don't want to make the effort to switch" and "having a high barrier keeps newbies out and we don't consider it a bad thing"
- u801e 6y ago
  > so bad it locks most people out. Could you specifically describe why it locks most people out? > I did contribute to Git, and the experience was horrible. What was bad about it? > The amount of time spent on the mailing part was far far greater and confusing than the amount of time writing code From what I've read on the mailing list, a lot of the time was spent discussing the patch or patch series in general. That's what should be done when submitting changes. What was confusing about it? > And I don't see how using github locks you in, switching to gitlab, bitbucket or whatever is dead simple. Well, with issues, metadata in PR discussoins, etc, migrating does take a bit of effort. What's simple about it? On the other hand, I could connect via NNTP to public inbox (or possibly gmane) and download 15+ years of patch series discussions in a couple of minutes.
  - Avamander 6y ago
    The single conclusive answer to your questions is "everything", absolutely every single component in that process is obsolete, cumbersome, finicky and convoluted. What's confusing about that description?
    - u801e 6y ago
      > that process is obsolete, cumbersome, finicky and convoluted. It just sounds like you don't like the process since you apparently aren't able to express a specific issue with it. Here's what I don't like about Github 1. You need to set up an account on there (I already have an email account) 2. You need to fork a repo rather than just simply cloning it. This means you have to go through a rather convoluted process to keep your fork up to date with the original repo. That either involves setting up another origin pointing to the original repo and then pushing up those changes to your forked repo (and taking into account any branches you updated). Or you have to delete the forked repo, fork it again and then have to somehow resolve possible conflicts when running git pull. 3. It's not possible to comment on a commit message itself This means that I need to comment on the first line of the diff for that commit or I have to edit the url to navigate to the commit itself and then type stuff into a comment box at the very bottom of the diff. Then that comment doesn't show up with any context other than saying "github-user commented on abcdef1". And those comments disappear when someone force pushes to the branch to update the commit. If the comment is associated with the first line of the diff for that commit, it either is collapsed or not depending on whether the line changed. I still have to go to the commit view to check whether the updated commit message addresses my comment. 4. It collapses comment threads when the line of code changes regardless of whether the change pertains to the original comment. This means I have to scroll from the top of the conversation view page and search for collapsed comment threads to find the comment I made, then go to the diff view to compare that line with what's in the current diff to determine whether the change actually addresses a comment I made 5. It's not easy to jump between different revisions of the branch over several force pushes in a way that makes it easy for me to see what changed on a per commit basis 6. It doesn't provide a way to distinguish different subthreads of conversations on the same block of code 7. It requires far more scrolling in the conversation view when there are a lot of comments on a pull request As for email, all I need to do is 1. Run a few git config commands to set up git to send email using my existing email account (this is a one type step) git config --global --add sendEmail.smtpServer "your.server" git config --global --add sendEmail.smtpServerPort 587 git config --global --add sendEmail.smtpEncryption tls git config --global --add sendEmail.smtpUser "your.email.username" 2. Clone their repo, check out the appropriate branch, make your own branch and do your work If the upstream repo is updated while you do you work, you can simply run git fetch and rebase your local branch on top of the updated branch, which is a lot less convoluted compared to what you have to do to keep a Github forked repo up to date. 3. Create your patch files with cover letter git format-patch --to email.list.address --cover-letter base-branch 4. Edit the cover letter file and update the subject and body to include your patch series description (which isn't much different than composing the PR description on Github) 5. Run git-send-email to send your patch series to the email list git-send-email *.patch 6. Check your email for replies, engage in addition discussion, etc (which is better than having to scroll through a large diff to find every comment) 7. Update your code, rebase 8. Run git format-patch the same way but add -v2 to indicate a reroll 9. Run git-send-email and reference the message-id of the original cover letter In terms of engaging in discussion over email, one can reply inline and comment on any part of the cover letter, commit message, line in the patch etc. One can save the emails from multiple patch series, run git am to apply them in different branches locally and run git diff or git range-diff to check what's changed. That's not possible in Github if someone force pushes to the branch because there's no longer a remote branch to fetch to allow for a comparison. In any case, I would certainly be interested to read your specific complaints about the email based process instead of just a dismissive reply.