4 ms·

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 horrib

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.
    - Avamander 6y ago
      > It just sounds like you don't like the process since you apparently aren't able to express a specific issue with it. I don't like the process because it has so many issues. It's just hostile in so many ways if you aren't using a VT-100, it's fundamentally flawed because of the assumptions it makes. > I would certainly be interested to read your specific complaints about the email based process instead of just a dismissive reply. I'm no longer interested in being specific because it's an evangelical issue, where the other side is just not interested in improving the process no matter how detailed you are, in the end the reply will just be "it's all so perfect, look how easy and nice it is". I also know that being specific with an evangelist will just get me a reply "oh just rent a VPS if your ISP blocks SMTP", I've played this game before. Just like you just did. If you really can't admit to see a single fault with the system, you are evangelical. That's not necessarily a bad thing, but it doesn't really allow any discussion on the topic.
      - u801e 6y ago
        > I don't like the process because it has so many issues And you still haven't described any of them. > It's just hostile in so many ways if you aren't using a VT-100 That's a strawman. At some point, you're going to have to use git on the command line to stage code, push it up to the remote or pull new code from the remote. You're going to have to learn how to deal with code conflicts, resolve them and push up the resolution. You can certainly participate in the email patch workflow with a GUI email client and a few git commands either executed on the command line, or may be as part of a graphical git GUI client. > where the other side is just not interested in improving the process I already mentioned a few things in my reply to williamdclt pertaining to tl; dr documentation for setting up git format-patch and git send-email much like Github displays the commands to clone, set the remote, push and pull commits. But I don't think it's fair to say they're not interested in improving the process. For example, a new utility called GitGitGadget was written to provide an interface between Github pull requests and the Git mailing list and it's also mentioned in the Documentation folder of the git repository [1]. > in the end the reply will just be "it's all so perfect, look how easy and nice it is" The problem is that you're being too dismissive in your criticism and comments rather than specifically describing what could be improved within their process. Effectively telling a project that they need to discard a process that they've successfully used since its inception and move to an entirely new process is a non-starter. > I also know that being specific with an evangelist will just get me a reply "oh just rent a VPS if your ISP blocks SMTP" Some people prefer to run their own SMTP servers rather than use Big Company's product. In my case, I have no problem doing this through the email account I have with my ISP. > If you really can't admit to see a single fault with the system, you are evangelical. I did mention in my other reply that the documentation for setting up the environment could be more concise, but not everything that's old is necessarily worse or obsolete. A lot of Webapps perform worse in terms of latency and input lag on my laptop with a multicore processor, gigabytes of memory and over a terabyte of secondary storage compared to the equivalent desktop application from decades ago on a machine with megabytes of memory, a single core processor running at less than a quarter GHz and secondary storage less than a quarter GB. [1] https://github.com/git/git/blob/master/Documentation/MyFirstContribution.txt https://github.com/git/git/blob/master/Documentation/MyFirst...

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.
  - Avamander 6y ago
    > It just sounds like you don't like the process since you apparently aren't able to express a specific issue with it. I don't like the process because it has so many issues. It's just hostile in so many ways if you aren't using a VT-100, it's fundamentally flawed because of the assumptions it makes. > I would certainly be interested to read your specific complaints about the email based process instead of just a dismissive reply. I'm no longer interested in being specific because it's an evangelical issue, where the other side is just not interested in improving the process no matter how detailed you are, in the end the reply will just be "it's all so perfect, look how easy and nice it is". I also know that being specific with an evangelist will just get me a reply "oh just rent a VPS if your ISP blocks SMTP", I've played this game before. Just like you just did. If you really can't admit to see a single fault with the system, you are evangelical. That's not necessarily a bad thing, but it doesn't really allow any discussion on the topic.
    - u801e 6y ago
      > I don't like the process because it has so many issues And you still haven't described any of them. > It's just hostile in so many ways if you aren't using a VT-100 That's a strawman. At some point, you're going to have to use git on the command line to stage code, push it up to the remote or pull new code from the remote. You're going to have to learn how to deal with code conflicts, resolve them and push up the resolution. You can certainly participate in the email patch workflow with a GUI email client and a few git commands either executed on the command line, or may be as part of a graphical git GUI client. > where the other side is just not interested in improving the process I already mentioned a few things in my reply to williamdclt pertaining to tl; dr documentation for setting up git format-patch and git send-email much like Github displays the commands to clone, set the remote, push and pull commits. But I don't think it's fair to say they're not interested in improving the process. For example, a new utility called GitGitGadget was written to provide an interface between Github pull requests and the Git mailing list and it's also mentioned in the Documentation folder of the git repository [1]. > in the end the reply will just be "it's all so perfect, look how easy and nice it is" The problem is that you're being too dismissive in your criticism and comments rather than specifically describing what could be improved within their process. Effectively telling a project that they need to discard a process that they've successfully used since its inception and move to an entirely new process is a non-starter. > I also know that being specific with an evangelist will just get me a reply "oh just rent a VPS if your ISP blocks SMTP" Some people prefer to run their own SMTP servers rather than use Big Company's product. In my case, I have no problem doing this through the email account I have with my ISP. > If you really can't admit to see a single fault with the system, you are evangelical. I did mention in my other reply that the documentation for setting up the environment could be more concise, but not everything that's old is necessarily worse or obsolete. A lot of Webapps perform worse in terms of latency and input lag on my laptop with a multicore processor, gigabytes of memory and over a terabyte of secondary storage compared to the equivalent desktop application from decades ago on a machine with megabytes of memory, a single core processor running at less than a quarter GHz and secondary storage less than a quarter GB. [1] https://github.com/git/git/blob/master/Documentation/MyFirstContribution.txt https://github.com/git/git/blob/master/Documentation/MyFirst...