4 ms·

> 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 n

by u801e 6y ago

> 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. [1] https://tools.ietf.org/rfc/rfc3676.txt https://tools.ietf.org/rfc/rfc3676.txt

Avamander 6y ago
> 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.
- u801e 6y ago
  >> 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. [1] https://tools.ietf.org/html/rfc5321#section-4.5.3.1.6 https://tools.ietf.org/html/rfc5321#section-4.5.3.1.6

by u801e 6y ago

Avamander 6y ago

> 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.

u801e 6y ago
>> 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. [1] https://tools.ietf.org/html/rfc5321#section-4.5.3.1.6 https://tools.ietf.org/html/rfc5321#section-4.5.3.1.6