And his email client hard-wraps at 80 chars, because that's the standard of both Linux and Git mailing lists, because they send patches in emails. I like the irony :)
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"
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.
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?
> 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)
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.
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.
Not answering your points against GitHub, they're valid and I mostly agree on them.
About your "for email all I need to do is": this looks simple and neat (and even then, does it really?) when you already know how it works. But it took me several hours of googling around to understand what I was supposed to do (I need to configure git to send emails?), how to do it (get the right sendEmail config is non-trivial), learn about multiple git commands I never heard about and never used outside of this process (format-patch, am, send-email) and their various flags, iterate to get the correct flags while quadruple-checking everything to make sure I don't send garbage on the mailing list and bother everybody, get told I didn't respect a half-dozen conventions (no HTML in emails, 80-char lines, format of the commits, the email subject and the cover letter, people CC'd...), iterate several times to finally have a patch that respects enough conventions that people are OK looking at it. I had to change my email client because it's basically impossible to respect these conventions or follow discussions without a specialised client à la Mutt, which meant more hours downloading, configuring and learning a new tool. And then I get feedback fragmented over several emails instead of a single interface, spend a ridiculous amount of time answering to make sure you respect conventions, never have a clear resolution of a feedback.
I submitted a copy change patch about a year after my first patch, and it still took me hours to get it right.
The process you're explaining makes sense and seems simple when you are already familiar with it. When you're not, it's just hours of head scratching and trying to make sense of it. Which would be fine if that was a process everybody used, we'd just learn it and practice, but nowaday very very few projects use it: I've never had to go through all these hoops ever again. Which makes it a crazy high barrier to entry and feel old and obsolete. And maybe the high barrier to entry is considered a good thing by git/linux people, it's their right, but let's not pretend it doesn't exist
> About your "for email all I need to do is": this looks simple and neat (and even then, does it really?) when you already know how it works
At one time, I didn't know how it worked, but I read through the documentation (man pages for git, git format-patch, git send-email, and git am).
To be fair, when you create a new repo or fork a repo, Github will display the commands necessary to set your repository's origin or cloning the repository. It probably also tells you the commands necessary to push commits to the remote or pull from it.
There is documentation out there that gives you a general idea about how to submit patches, coding conventions, etc in [1]. It certainly would be nice if they added a short tl; dr section on how to configure git for using the format-patch and send-email commands (similar to what I did in my previous post).
> get told I didn't respect a half-dozen conventions (no HTML in emails, 80-char lines, format of the commits, the email subject and the cover letter, people CC'd...),
This is all documented in the SubmittingPatches file in the git repo itself in the Documentation directory. The maintainer and major contributors have to go through a lot of submitted patches and they, for better or worse, will apply a filter on what they accept. But reading through a text file to learn the conventions and requirements shouldn't be considered a barrier to entry.
> while quadruple-checking everything to make sure I don't send garbage on the mailing list and bother everybody,
The best way to do that is to test it against your own email account.
> I had to change my email client because it's basically impossible to respect these conventions or follow discussions without a specialised client à la Mutt,
A GUI client like Thunderbird would have worked for viewing threaded conversations and participating in them. In fact, there are a number of GUI email clients that support threaded view [2] (but would need to be configured to only send plaintext email). Submitting patches, on the other hand is best accomplished by using the format-patch and send-email commands since they ensure correct formatting. But the project could certainly do a better job documenting the actual set of commands and flags used for generating the patches and then submitting them (along with re-rolls). But the lack of concise documentation for the settings and workflow isn't something that makes the email workflow inferior or obsolete.
> then I get feedback fragmented over several emails instead of a single interface
The feedback is on a per commit basis. A patchset consisting of multiple commits can make for a large diff and make it more difficult to review (and require far more scrolling to view the diff and the comments in the Github conversation view). An email client with an index view of the commits along with their associated comment threads makes it easy to see which comments have been read or not, what you've replied to, etc.
> Which makes it a crazy high barrier to entry and feel old and obsolete. And maybe the high barrier to entry is considered a good thing by git/linux people, it's their right, but let's not pretend it doesn't exist
I guess the real argument comes down to whether reading documentation and reading through the mailing list before submitting a patch should be considered a high barrier for entry. Regardless of whether a project is managed via email, Github/Gitlab, or some other tool like Gerrit or Phabricator, there are always some conventions to follow in terms of code organization, style, commit message conventions, etc. At some point, one will have to learn by observing how things work from previous submissions and/or read through the documentation. There may be people who are willing to lead others through the process and show them what to do, but, that's not always the case.
I guess you could think of it as joining in a game that people are playing (soccer, basketball, poker, etc), but not knowing the rules. You could either read up on the rules beforehand and watch how they play before joining in or just start participating and learn as you play. But if you keep making mistakes and not respond to feedback, then others will be less inclined to work with you.
> 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.
> 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.
How? That workflow assumes a 80-char b/w terminal for the most part. Try using any part of it on mobile or with large font size due to bad eyesight, it's awful.
> 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.
Well... no, you don't have to.
> In my case, I have no problem doing this through the email account I have with my ISP.
In your case...
> 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.
I have tried being very specific, just one sentence later you prove my point, it doesn't work and gets dismissed. I really don't plan on playing that game until I die of old age. Thankfully GitLab/GitHub et al have started the "fight" for me, making the workflows much more accessible and losing quite a few B/G-era relics.
> 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.
Yeah, this is exactly the answer I spoke about and have gotten, blanket dismissal and being set in old ways. There isn't a piece of workflow that they're/you're willing to move out of that toolset. Quite a few projects still enforce 80char columns, it's a testament to the fact that even the smallest things can't be changed.
> 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.
Yeah and you uploaded your patchsets for minutes if not hours. God forbid you had to download anything with any size at all, sometimes it took days. The non-stop hassle of having enough disk space. Delivering files via snail-mail and floppies was sometimes a viable option. Not to mention the equal amount of rather buggy and cumbersome software.
It wasn't all bunnies and flowers you are trying to imply it was. Some half-a-second slowdown, some minor input latency is not a valid reason to dismiss an entire set of tools. Not to mention, git doesn't really shine with it's responsiveness in quite a few cases.
> How? That workflow assumes a 80-char b/w terminal for the most part.
There's nothing stopping you from using a gui text editor to edit the code and there's nothing in git commits or the code itself that forces wrapping at 80 characters. Email clients certainly can wrap text at longer line lengths if configured to do so.
> Try using any part of it on mobile or with large font size due to bad eyesight, it's awful.
I don't try to do any serious development on my mobile. Having a machine with a reasonable size screen along with an actual keyboard makes things much easier.
If you're referring to hard wrapping, you're probably going to have to deal with that for most source code anyway no matter what line length. Soft-wrapping lines that exceed the screen width makes code and diffs less readable. For text in the email that doesn't require hard wrapping, there is an RFC[1] that defines a additional format parameter for the Content-Type header. Clients that support it will softwarp text, but email clients that don't will just show the original hardwrapped version.
> I have tried being very specific, just one sentence later you prove my point, it doesn't work and gets dismissed.
The git project, specifically, has been using this process since its inception (around 2005 IIRC). They inherited it from the Linux project which had been around for several years longer than that. In fact, the process pre-dates git itself and git was written with that process in mind (which is why they have commands that can serialize commits to and deserialize them from email).
But, like I said, telling a group of people as an outsider that they should drop the long standing process entirely which has been working well for them and go with something different isn't going to gain any real traction. This is regardless of the domain you're dealing with.
> Yeah and you uploaded your patchsets for minutes if not hours.
Most patch sets probably don't exceed several hundred lines total. Even on dial-up, you're talking about less than a minute.
> God forbid you had to download anything with any size at all, sometimes it took days.
Patch sets aren't really that big. The only thing that took a while with email or newsgroups was messages with attachments or having to download a lot of headers. As for git, the only process that may take a while is git clone. git fetch and dealing with email would work just fine over dial-up.
On the other hand, I seriously doubt that webapps like Github or Slack can work over dial-up speeds. For instance, if I have people at home streaming video while I try to use Slack or Github, they're essentially not usable, but I can still receive and send email without any issues.
> It wasn't all bunnies and flowers you are trying to imply it was.
If you were talking about downloading images, mp3s, etc, then, yes, it took a while, but those things aren't relevant to text patches, email, or git.
> Some half-a-second slowdown, some minor input latency is not a valid reason to dismiss an entire set of tools.
I use Slack and Github Enterprise at work. On a 100 Mbps downstream connection, I have to wait for 10 to 20 seconds for a PR to load up when it has more than 20 comments. When I type in Slack, there's a noticable input lag that develops over time (on the order of seconds) and I have to refresh the Slack window several times a day to get rid of it). Sometimes, I try to mark messages as read and my browser tab freezes until it gives me a prompt about a script causing a slowdown. If I stop it, then Slack is unusable and I have to refresh the page to recover.
I simply don't recall having these issues with email or IRC (or even some of the other chat clients like ICQ, AIM, MSN Messenger, etc), and all of them worked perfectly fine over dial up and on machines that significantly less computation speed and available memory.
> Not to mention, git doesn't really shine with it's responsiveness in quite a few cases.
It really depends on what you're using git for. If you're storing large binary files or very big mono-repos, then it's not the right tool to use. Similarly, tools like Github aren't the right tool to use for certain projects that deal with many in flight patch sets that require in depth discussion and not having the platform shut down accounts of certain users due to issues the US government has with a number of other countries around the world.
> there's nothing in git commits or the code itself that forces wrapping at 80 characters
Very clever leaving out the third component here that does force it.
> Email clients certainly can wrap text at longer line lengths if configured to do so.
Assuming someone hasn't banally pre hard-wrapped the text.
> I don't try to do any serious development on my mobile.
Who said anything about serious development, you basically can't even check a patch out on mobile without some major hassle. Plus you also ignored the general accessibility problems.
> If you're referring to hard wrapping, you're probably going to have to deal with that for most source code anyway no matter what line length.
Source code can be displayed using a code viewer, nicely, it works. Comments can be displayed using a text viewer, using text fonts, nicely, it works. Non-HTML e-mail conflates the two, the resulting amalgam is vomit-inducing.
> But, like I said, telling a group of people as an outsider that
Nah, this reply is given to even insiders that don't want to deal with that obsolete shit.
> they should drop the long standing process entirely which has been working well for them and go with something different isn't going to gain any real traction. This is regardless of the domain you're dealing with.
I can say my ten-year-old laptop "works so far", but is it good, no, not really. It's really a rather weak argument to resist even changing the tiniest things.
> if I have people at home streaming video while I try to use Slack or Github, they're essentially not usable
Fix your home network.
> but those things aren't relevant to text patches, email, or git.
You're still pretending that it was fast even with text patches, e-mails or git.
> simply don't recall having these issues with email or IRC (or even some of the other chat clients like ICQ, AIM, MSN Messenger, etc), and all of them worked perfectly fine over dial up and on machines that significantly less computation speed and available memory.
Yeah, you have other issues with IRC. Not to mention, no, they didn't "work perfectly over dial-up".
> It really depends on what you're using git for. If you're storing large binary files or very big mono-repos, then it's not the right tool to use.
It depends if you're using it or not. It's slow even on medium-sized repositories. Things don't happen in an instant like you pretend them to do.
>> there's nothing in git commits or the code itself that forces wrapping at 80 characters
> Very clever leaving out the third component here that does force it.
Which component is that? The SMTP protocol? According to [1], the maximum line length allowed by SMTP is 1000 octets, which is well over any maximum hard-wrapped line length for typical source code lines.
> Assuming someone hasn't banally pre hard-wrapped the text.
Hardwrapped text is only a problem for displays that cannot display lines as long as the hardwrapped line length. It's not a problem for displays that can display lines longer than that. To me that indicates that if enough people are using mobiles to read code and patches, then we should consider line length limits significantly less than 80 characters.
> you basically can't even check a patch out on mobile without some major hassle.
Mobile email clients are not suited for reviewing patches due to the fact that they typically use variable width fonts and do not provide a way to post replies inline with quoted text. But that certainly could be fixed by connecting to a machine and attaching to a screen or tmux session to review a patch.
> Nah, this reply is given to even insiders that don't want to deal with that obsolete shit.
Citation please.
> I can say my ten-year-old laptop "works so far", but is it good, no, not really. It's really a rather weak argument to resist even changing the tiniest things.
Changes should improve on what's there, not go off on a different tangent. Github wasn't even originally designed for code review and it shows. The fact that you can't have threaded discussions (like Hacker News or reddit, not like Facebook) or Twitter) on a line of code, treating commits as something completely dissociated from the review doesn't sound like an improvement to me.
> Source code can be displayed using a code viewer, nicely, it works.
Looking at my python code on Github on my mobile, I find that I have to scroll from side to side to view the code which is wrapped to 79 characters or less for most lines. That's no different than viewing it in a window that does not softwrap the code. How would this be any different than viewing an email with the softwrap setting turned off?
>> if I have people at home streaming video while I try to use Slack or Github, they're essentially not usable
> Fix your home network
Why can't those tools work when I'm getting 5 to 10 kB per second downstream? Email and IRC work perfectly fine. It's the same thing if I only have a GPRS connection on my mobile. You might call protocols other than HTTP obsolete, but they still work when you don't have that much bandwidth.
> You're still pretending that it was fast even with text patches, e-mails or git.
Exactly how much experience do you have on the internet at dial-up speeds? I was using dial-up from 1995 through 2005. Emails, whether they contained correspondence or patches simply did not take a noticable period of time to transfer.
I'm not going to bother reading the rest of your response because you're just arguing for the sake of arguing.
> Which component is that? The SMTP protocol? According to [1], the maximum line length allowed by SMTP is 1000 octets, which is well over any maximum hard-wrapped line length for typical source code lines.
The wetware component enforcing some line length - some old maintainer stuck in his ways. I don't see what you're trying to achieve ignoring that?
> Hardwrapped text is only a problem for displays that cannot display lines as long as the hardwrapped line length
You're incorrect, it's a problem on wider screens as well.
> Mobile email clients are not suited for reviewing patches due to the fact that they typically use variable width fonts and do not provide a way to post replies inline with quoted text.
Again, that's an issue caused by non-HTML e-mail that's currently enforced in way too many places. It's not a problem with any e-mail system that is even somewhat modern.
> Why can't those tools work when I'm getting 5 to 10 kB per second downstream?
That's not the issue, your network's QoS is bad.
> Exactly how much experience do you have on the internet at dial-up speeds?
Years, more than enough to know it was absolute shit.
>> Nah, this reply is given to even insiders that don't want to deal with that obsolete shit.
> The wetware component enforcing some line length - some old maintainer stuck in his ways
You need to be more specific about what you're referring to when you bring something up. I already stated that email clients can be set to use longer line lengths. Are you aware that the default line length for hard-wrapped emails is 72 characters, not 80? It shouldn't take 4 posts for you to be specific enough for one to get what you're referring to and then basically ignoring the point I already brought up pertaining to that issue.
> You're incorrect, it's a problem on wider screens as well
Given the level of nesting in this sub-thread, the large amount of blank screen space to the left of the post is not posing any issues in terms of readability. I'd rather avoid "embarrasing line wrap" due to hard wrapped lines that are too long for the display. Also, the format=flowed option has solved this issue.
> Again, that's an issue caused by non-HTML e-mail
I assume you're aware of the problems caused by HTML email where people end up getting phished because of the anchor element with the hfref property set to make the link look like a legitimate website like their bank? Email should be plain text only. Leave the HTML to the web browsers.
> That's not the issue, your network's QoS is bad.
If the QOS was bad, then email and IRC would not work. They still do on the slow downstream and upsstream connection. And even if your claim of QoS was true, that doesn't explain why I experience the same issue on my mobile with a GPRS connection.
