3 ms·

> 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

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

Avamander 6y ago
> That's a strawman 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.
- 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

by u801e 6y ago

Avamander 6y ago

> That's a strawman 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.

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