Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Give up GitHub: The time has come

sfconservancy.org

Post reply on HN
Print view View original

91–100 of 585 posts

Re: Give up GitHub: The time has come

#91

Post by discreteevent »

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.

You could miss out on some good junior developers if you pick one thing they are ignorant about and reject them because of it. There are plenty of bright junior developers who don't know everything, have opinions on things that they think they know, but will work hard and pick things up once they get some time at it. Of course, if they outright refuse to use something then that's another story.

Re: Give up GitHub: The time has come

#92

Post by joshstrange »

Nemo157 wrote: post #82
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.

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 hill to care about, especially since it means ongoing development maintenance, testing, design/UI work, and the list goes on.

Re: Give up GitHub: The time has come

#93

Post by NoraCodes »

RoddaWallPro wrote: post #42
dmos62 wrote: post #39

The writing is a problem. It's a call to action, it's a history lesson, it's an opinion piece. And, it's a mess. This is not The New Yorker: I want to know the gist of what you have to say in the first paragraph, and I want intro and outro to be good summaries. Bonus points for a structure that let's me surveil the finer points easily.

Agreed. They use the word "problematic". Any time I see someone using that word, I close the tab instantly to avoid the brain damage that would result from me reading the rest of the piece. The word is meaningless and cowardly. Say what you think. Quit tap dancing around the conversation.

> The word is meaningless and cowardly.

It literally just means "has problems."

Re: Give up GitHub: The time has come

#94

Post by masklinn »

brundolf wrote: post #70
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…

I don't think it's fair to frame this as specific to GitHub, or even as a thing to wring hands over. New devs - especially those coming from bootcamps (I say this without judgement) - mostly start with practical skills. Industry-standard ways to just get things done. That's how you get a job, that's how you get off the ground. This goes beyond source-control; languages/frameworks, tooling, etc. You enter the territor…

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

Re: Give up GitHub: The time has come

#95

Post by NoraCodes »

vadiml wrote: post #78
happymellon wrote: post #7

Earlier quoted context omitted.

The main point is that it's a commercial service that doesn't respect other people's licences. Previously it was free and the noises that GitHub had given made it sound like it wasn't finished. Turns out it was.

If i read the code published on github and later i do not infringe on any license. If later i'm hired to implement some function chances are that i'll produce code which is similar to what i've learned from github. Or if somebody asks me on how to implement some function and i can respond: Hey that and that project on github already doing it, just use it, i'm not infringing on any license. Now, replace "I" in the abo…

Copilot is not a person.

Re: Give up GitHub: The time has come

#96

Post by mrits »

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…

git isn't easy to understand. I think the real irony is I spent the first decade of my career teaching senior engineers how to use distributive version control. So many older guys decided to just use the SVN shim instead of learn something new and useful.

Re: Give up GitHub: The time has come

#97

Post by rst »

blibble wrote: post #71

if you're worried about copilot: isn't the problem is that copyright law (apparently) allows them to do it? if you move everything to gitlab/self-hosted there's nothing stopping them spending 5 minutes querying the bing index and feeding it every repo they find

Well, they're asserting copyright law allows them to do it. It's not clear how well that would hold up in court against a well-funded lawsuit -- but that would require someone whose code got regurgitated substantially intact by Copilot, who also had the resources to manage the suit.

Re: Give up GitHub: The time has come

#98

Post by enriquto »

NoraCodes wrote: post #93
RoddaWallPro wrote: post #42

Earlier quoted context omitted.

Agreed. They use the word "problematic". Any time I see someone using that word, I close the tab instantly to avoid the brain damage that would result from me reading the rest of the piece. The word is meaningless and cowardly. Say what you think. Quit tap dancing around the conversation.

> The word is meaningless and cowardly. It literally just means "has problems."

...which doesn't mean anything at all (unless you are quoting firefly, of course).

Re: Give up GitHub: The time has come

#99

Post by remram »

cybrox wrote: post #52
NoGravitas wrote: post #47

I publish my public FOSS work on a self-hosted Gitea. I don't allow account creation, and people can send me pull requests by email. That said, I think one thing (other than interface and brand loyalty) that keeps FOSS projects on GitHub is network effects. You can reasonably expect to search it and find the projects you're looking for, and your account lets you use the issue tracker and pull requests on other projec…

> people can send me pull requests by email. Great, you already lost half of them.

Honestly it's not that bad. If you don't insist on getting correctly-formatted email for git-am, most people manage fine. They'll send you the output of git-diff, a git-bundle, or attach the files they changed.

Re: Give up GitHub: The time has come

#100

Post by rzwitserloot »

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…

Going through security certification procedure, I was asked to list all the third party SAAS things we use.

I didn't include github, gitlab, or anything else, because we don't use it. The auditor was going off on a tirade about how lack of version control is not okay at all, so convinced they were that 'no github or gitlab' must therefore mean 'no version control'.

The mind boggles. He barely believed me when I showed how git just syncs with other git repos and that's really the start and end of it.

This has actually gotten me into thinking about a few things. What a web site 'backed' by your git repo seems to get you is:

* Some insights to those who don't have a full git dump. Mostly irrelevant.

* CI stuff and hook processing, but this does not need to be done by the system that hosts git, or even a dedicated system in the first place.

* An issue tracker that nicely links together and that auto-updates when you commit with messages like 'fixes #1234'.

* Code signoff/review coordination.

And all of that should be possible __with git__, no?

If you have a policy that all code must be signed off otherwise it isn't allowed to be in the commit tree of your `main`, `deploy` or whatever you prefer to call it branch, then why not just say that a reviewer makes a commit that has no changes (git allows this with the right switches), _JUST_ a commit message that includes 'I vouch for this', signed by the reviewer? And that _IS_ the review?

What if issue tickets are text files that show up in git, to close a ticket you make a commit that deletes it. Or even: Not text files at all, but branches where the commit messages forms the conversation about the issue, and the changes in the commits are what you're doing to address it (write a test case that reproduces the issue, then fix it, for example), and you close a ticket by removing the branch from that git repo that everybody uses as origin?

Then all you really need is some lightweight read only web frontend so that the non-technically-savvy folks can observe progress on tickets in a nice web thingie perhaps, if that. But it's just a stateless web frontend that reads git commit trees and turns them into pretty HTML, really.

Commit hooks to ensure policies such as 'at least 2 sign-off reviews needed before the CI server is supposed to deploy it to production'.

Does something like that exist?

Post reply on HN