Give up GitHub: The time has come • Hacker News Board

Re: Give up GitHub: The time has come

#131

Post by ryanmcbride » Thu, Jun 30, 2022, 4:57 PM UTC

brundolf wrote: post #103

masklinn wrote: post #94

Earlier quoted context omitted.

> New devs - especially those coming from bootcamps (I say this without judgement) - mostly start with practical skills. I wouldn't say that it's "especially those coming from bootcamps". Those coming from uni are no better IME.

Depends on the uni. Mine focused on fundamentals, almost to a fault; we learned algorithmic complexity and relational normal-forms but never touched eg. JavaScript, Python, or - ironically - git. Practical skills were very much not the entrypoint; I had to learn most of that myself.

Yeah I had to learn Assembly in college. We also had to physically print out our C++ code and turn it in to the professor. Did it make me a better programmer? Maybe but to this day I still haven't had to use it. Most of my practical skills I picked up on the job.

P.S. I've seen the professor grading the printed out programs and he'd do it by flipping to the last page which was supposed to have the result output, and then fold the corner of the papers so it looked like he read the whole thing and then put a grade on the top. It was pretty funny.

Re: Give up GitHub: The time has come

#132

Post by josephcsible » Thu, Jun 30, 2022, 4:58 PM UTC

joshstrange wrote: post #54

pabs3 wrote: post #32

Earlier quoted context omitted.

GitLab is mentioned on the advocacy page https://giveupgithub.org/ . GitLab is an open-core business, which means there is a permissively licensed FOSS version and a proprietary version. The gitlab.com website uses the proprietary version. In addition many features of GitLab don't work at all or work much less well if you turn off JavaScript. They have swayed a lot of ostensibly FOSS, copyleft-leaning and privacy/sec…

> In addition many features of GitLab don't work at all or work much less well if you turn off JavaScript. I feel like the venn diagram of people who complain about JS being required and of people who have never had to code up a web /app/ that users expect rich interactions without a page-reload is just a circle.

You make it sound like it's impossible to build a Web app that supports rich interactions without a page-reload without requiring JavaScript, but this isn't true. You can use progressive enhancement/graceful degradation to build one such that users with JavaScript still get the experience they get now, while users without it will have an experience that's slightly clunkier but still usable.

Re: Give up GitHub: The time has come

#133

Post by dividedbyzero » Thu, Jun 30, 2022, 4:59 PM UTC

prepend wrote: post #56

BeetleB wrote: post #46

Earlier quoted context omitted.

2 years ago, while interviewing internally, I asked the team what VC they use. It was Team Foundation's proprietary VC (and not a DVCS). I mentioned to them that even MS recommends Git for Team Foundation's usage. "Well of course, MS invented Git!" Wrong on so many levels: 1. Conflating Github with Git. 2. They bought it, not invented/founded it. 3. Most importantly, MS's recommendation to use Git for TF existed long…

> refusal to use Git[1] due to its complexity I kind of like this friction. If a software developer finds git too complex, that’s an important signal that I should minimize my exposure to them. I’d never work in a team that dumb, and I wouldn’t want any dependencies on their code. Of course there are other reasons not to use git, but complexity is not one.

My take is completely opposite from yours. I think it's great when someone "gets" that git is an extremely powerful and capable tool with a horribly unintuitive user interface. Whether you call that "complexity" or just "terrible UX", to me that's a sign that someone has good instincts regarding the risks associated with this kind of "complexity". Whether I agree that a decision to shun git for that reason is justified depends on the specific situation.

> ... that I should minimize my exposure to them. I’d never work in a team that dumb ...

That sort of arrogance is an important signal to me that I should limit my exposure to the people displaying it. I personally see this sort of attitude as a sign that there may be a dangerous lack of empathy on their side, and I've seen that go south too often.

Re: Give up GitHub: The time has come

#134

Post by duxup » Thu, Jun 30, 2022, 5:00 PM UTC

This isn't very compelling to me.

SourceForge went bad ... and everyone left. That doesn't seem like a bad thing and there's no reason for me to think any given site / service will or won't go bad too. I expect that for any number of reasons I might need to move from one site to the next.

The rest too is kinda hollow to me. The fact that they're for profit doesn't upset me. I figured they wanted to make a profit when I signed up even ... not sure how that would surprise anyone now.

Co-pilot, I personally don't feel there is a compelling reason to leave github due to that either.

Maybe I'm not versed enough in some of this but as a rando dev I'm just not having any problems on github these days ...

I'm not saying the author is wrong or right or that I'm right or wrong, just that I'm not finding that article very convincing.

Re: Give up GitHub: The time has come

#135

Post by ryanmcbride » Thu, Jun 30, 2022, 5:00 PM UTC

travisgriggs wrote: post #5

> For its part, Git was designed specifically to make software development distributed without a centralized site. Just yesterday I had to explain the basic premise/history of Git to a young intern. I had asked him if he was using Git to manage his little pet project the company gave him to play with. “No”, he replied, he didn’t know what the company’s policy was to posting code in public on GitHub. As I explained to…

The finer parts of git and other day-to-day tools seem to almost always be picked up on the job. I've seen this confusion of git/github before, but the one I always notice is when I'm interviewing someone and they say they have node on their resume but don't know that node isn't just a webserver, they really only used it as an express server and many didn't even know that it could touch the filesystem.

It's usually not a problem since they tend to already know javascript and can get things working by referencing the node api docs, but it's still really funny to me every time it happens. There's lots of stuff people don't know until they know.

Re: Give up GitHub: The time has come

#136

Post by u801e » Thu, Jun 30, 2022, 5:01 PM UTC

dcz_self wrote: post #109

u801e wrote: post #105

Earlier quoted context omitted.

Based on your first example of running git send-email without providing it any patch files or revision list, you appear to be making the assumption that someone doesn't bother reading the documentation before using the tool. This would be like someone trying out make the first time and not realizing why it isn't working becaue they didn't realize they need literal tab characters in the make file for the rules to work…

That's a valid observation of one of the reasons I won't use git-send-email. I have limited mental resources, and given the choice between a tool where I have to spend half an hour before I can begin using it, and a tool which will guide me, I'll always choose the latter. After I'm done, I can even forget I ever used the latter tool! It's a boon for one-offs. Keep reading, there's more criticism on other aspects of t…

After reading through the rest of the post, I do see your point. When I last tried it, I thought that most of the email formatting should be done with git format-patch and then git send-email should be used to actually send the email without having to answer any questions.

That would address one of your concerns about saving the email on disk and also ensuring that the headers have the correct contents.

If the project's contrib document contained information about what settings to use for format-patch and send-email, then the process would be much more seamless. I haven't looked at the kernel (or subsystems) documentation on that. The git project itself doesn't seem to contain that information though.

Regarding your other point about using your email client to handle sending the emails, git does have a utility called imap-send that would allow you to upload the patches to an IMAP folder, which, I believe, would allow you to then send the messages using your MUA of choice instead of git send-email.

Re: Give up GitHub: The time has come

#137

Post by nyanpasu64 » Thu, Jun 30, 2022, 5:01 PM UTC

joshstrange wrote: post #92

Nemo157 wrote: post #82

Earlier quoted context omitted.

JS being required for the interactive features would be fine. My personal problem is that I end up on some random gitlab instance to just take a look at the source or issues for some library, and get a blank white page. For the read-only public view there should be no need for any JS.

I understand that thinking but it's ignores reality. To do what you want you want means maintaining 2 codebases (even if just for sub-parts of a site). It's really easy to say "This specific page could be static" and you are right, it could, but it would mean having fallbacks for every JS interaction on the page (or removing them if the user has JS disabled). There simply aren't enough people who die on the no-JS hil…

GitLab is built on JS and renders a white screen without JS. Enabling JS at all taxes my Core 2 Duo machine, and opening GitLab to a few thousand line file (or worse yet, opening the pull request diff view) taxes my top-of-the-line Ryzen 5 5600X machine running Firefox. GitLab is just badly written.

Re: Give up GitHub: The time has come

#138

Post by UglyToad » Thu, Jun 30, 2022, 5:01 PM UTC

wiz21c wrote: post #118

UglyToad wrote: post #110

Where does this end? You write a license that your GPL code can only be re-hosted on non-GitHub hosts? git still exists, if I'm unhappy with GitHub I can just add a new origin (sourcehut, gitea, gitlab, self-hosting, etc) and push there. But I'm perfectly happy with GitHub and I'm fine if their ML thingy makes money off my code, I get free actions runners, a nice UI, pull-requests, etc, into the bargain, not bad. Lik…

> But I'm perfectly happy with GitHub and I'm fine if their ML thingy makes money off my code, I get free actions runners, a nice UI, pull-requests, etc, into the bargain, not bad. As an indivdual you can certainly think so. But as a community we must balance how much advantages do we get from GitHub versus how much advantages it gets from us. Considering that GitHub will probably make millions with copilot, then it…

Sure they're going to make more money from me (as a generic user) than value I will derive from them (on average over the population of users). Otherwise they go out of business and we use other available alternatives.

But you know what? Even after copilot my code is still there, for people to make money from (as both GH and random people already do), to learn from, to cut up and rehash, to reference, to write (much) better versions of, to generally advance humanity. I know this is the root philosophical conflict between free software and open source but I wanted to state my view since this is a call to action and we'll be seen as betraying some ideal for failing to comply.

Re: Give up GitHub: The time has come

#139

Post by josephcsible » Thu, Jun 30, 2022, 5:01 PM UTC

outside1234 wrote: post #34

"Open source zealot gets angry that there is something that works better than the pure open source version and shoots off foot to spite arm."

https://www.forbes.com/sites/hillennevins/2021/11/24/the-par...

You're only better off using GitHub today in the same sense that a turkey being fattened up for Thanksgiving is better off today than one living in the wild.

Re: Give up GitHub: The time has come

#140

Post by joshstrange » Thu, Jun 30, 2022, 5:02 PM UTC

josephcsible wrote: post #132

joshstrange wrote: post #54

Earlier quoted context omitted.

> In addition many features of GitLab don't work at all or work much less well if you turn off JavaScript. I feel like the venn diagram of people who complain about JS being required and of people who have never had to code up a web /app/ that users expect rich interactions without a page-reload is just a circle.

You make it sound like it's impossible to build a Web app that supports rich interactions without a page-reload without requiring JavaScript, but this isn't true. You can use progressive enhancement/graceful degradation to build one such that users with JavaScript still get the experience they get now, while users without it will have an experience that's slightly clunkier but still usable.

And as I said in reply to a sibling comment: Then you are effectively maintaining 2 codebases. Also, I'm not aware of any SPA framework (at least the big 3) that even offer an escape hatch to do something like that. Maybe with SSR and some special logic you could but it would be painful and ultimately not worth it.