Live data from Hacker News

Introducing unlimited private repositories

github.com

371–380 of 662 posts

Re: Introducing unlimited private repositories

#371
post #306

Earlier quoted context omitted.

In a non-profit that I collaborate with [1] we use private repos to keep the server setup and some tickets that contain sensitive information (user data). All other code is open source. Obviously we don't want to keep api keys etc. in the public repos. [1] https://github.com/sozialhelden/wheelmap

> we use private repos ... that contain sensitive information (user data). Wait, what?

email addresses and (account) names of people reporting bugs in private. Some people prefer it that way. Nothing "sensitive sensitive". Sorry for being unclear.

Re: Introducing unlimited private repositories

#372
post #329

Earlier quoted context omitted.

I'm curious, as a solo dev, had you considered bitbicket?

I've used BitBucket as a solo dev working on personal projects, a solo consultant, and an employee on a team. It's pretty mediocre, especially if you look beyond its integration with the rest of the Atlassian ecosystem. The number of times I've wanted to search a repo for something only to have to clone it and search in my IDE is staggering.

Same for me - lack of searching kills me every time!

Re: Introducing unlimited private repositories

#373

Earlier quoted context omitted.

In a non-profit that I collaborate with [1] we use private repos to keep the server setup and some tickets that contain sensitive information (user data). All other code is open source. Obviously we don't want to keep api keys etc. in the public repos. [1] https://github.com/sozialhelden/wheelmap

You shouldn't be keeping api keys or other sensitive information in git at all . And please note -- if you do remove it from git, it will be available in your git history so that needs to be taken care of as well (should the repo ever become public -- a common "exploit").

care to explain why? I need to keep my API keys somewhere so I can roll them out to the machine. Keeping them in git is as good as any storage - what would you propose instead? A shared dropbox account?

Re: Introducing unlimited private repositories

#374

Earlier quoted context omitted.

Even for software houses, it's VERY problematic as we add customers to projects as external collaborators and we're going to get billed for that forever, even if most customers have very light usage, and even for non active projects. I was thrilled by this news but it's going to be completely unaffordable for us. We have 29 users and 51 external collaborators. We have recently upgraded to the Platinum plan ($2460/yr)…

It feels to me like there needs to be a distinction between users and developers now they've changed their pricing model, with developers getting full git access, and users getting read-only source viewing through a browser, issues, and wikis. That way agencies can add customers for collaboration without having thousands of users to pay for.

great idea

Re: Introducing unlimited private repositories

#375
post #343
post #278

Earlier quoted context omitted.

We have about 100 private repos at the moment, including internal tools, branding related components, infrastructure code and pre-release stuff that we're not developing in the open. We may just move those to AWS code commit, gitlab or gogs and switch back to a free org.

"that we're not developing in the open" Honest question... why? I totally understand the mindset of "gotta go all secret squirrel to protect our profits" but if your org isn't in it for the profits there's not much to protect? I have seen examples of people performing very naughty acts like private repos to hold plain text passwords, plain text cloud service keys, plain text corporate credit card numbers for expense…

Non-profit organizations still have a mission that they need to protect, and they almost always have revenue they care about, though not profit.

Private repos are a good way to review code for things like plaintext passwords and service keys before it's in production. If a developer commits something with a key, and code review goes "Oh, you shouldn't have put that there," and it was public, now you have to rekey. Private repos allow that code review step to take place.

(They're also pretty useful for legacy code where eliminating all the private keys is difficult and not an immediate priority, and for the rare but existent cases where including private keys in source is the right engineering tradeoff for new development.)

There's also no way to disable pull requests and other outside comments on your code, other than making a private repo. Having it private is a simple way to avoid inviting the public to have opinions all over your repo.

Re: Introducing unlimited private repositories

#376

1. Take a gazillion dollars in funding on an over-hyped valuation, 2. Go through significant organizational changes that end up with the departure of a co-founder (and more suits in the building). 3. Notice that a significant segment of your growth (VC-funded startups) are running out of money. 4. Switch to a user-based pricing to generate more revenue for investors, but spin it as a freebie "Hey! Look at the cool un…

I use GitHub for my public repos, but use Visual Studio Online (poorly named, since it is not actually Visual Studio) for my private ones (also unlimited, but free.) I know a lot of others that use Bitbucket, etc because of GitHub's pricing. I feel like GitHub would make more sense to smaller devs, like myself, if it were bundled with other services. Like, if they partnered with Microsoft, Google & Amazon and offered some sort of bundling packages with their cloud services. I don't know, to me GitHub...from a small dev perspective only makes sense to share things publicly. I'm sure this new pricing model will help push some smaller devs onto the platform, but it's hard to compete in that space when you have others providing private repos for free.

Re: Introducing unlimited private repositories

#377

Earlier quoted context omitted.

Majority user, here. I already pay GitHub monthly because I have some repos that I want private. I'm a solo dev, only hacking on side projects that may or may not be something one day, but want to keep them private anyway. My bill is about to go down, and my benefits go up. All in all, I'm quite alright with this change, agree that it's positive. I get that it gets worse if I ever take on N number of developers, but…

I'm curious, as a solo dev, had you considered bitbicket?

Yeah, but GitHub got me early on before I cared about private repos, and honestly I was just too lazy to move stuff over. They also win me over with integrations, though I'm sure BitBucket has a similarly expansive set now. Had I ever gone full Atlassian, I'd have switched, but never wanted to add Jira to my life badly enough (though when I was seriously working on a project with a friend, I considered it).

Re: Introducing unlimited private repositories

#378

Earlier quoted context omitted.

In a non-profit that I collaborate with [1] we use private repos to keep the server setup and some tickets that contain sensitive information (user data). All other code is open source. Obviously we don't want to keep api keys etc. in the public repos. [1] https://github.com/sozialhelden/wheelmap

You shouldn't be keeping api keys or other sensitive information in git at all . And please note -- if you do remove it from git, it will be available in your git history so that needs to be taken care of as well (should the repo ever become public -- a common "exploit").

Git is just a format for storing data with a record of how that data changed. Saying you shouldn't store it in git seems rather like saying you shouldn't store it in btrfs. It's true that if your btrfs disk image becomes public, the data is recoverable, and it's hard to reliably scrub deleted files from btrfs, but that doesn't mean it's the wrong tool for a filesystem (or a repo) that stays entirely internal.

Saying that you shouldn't keep it on GitHub is different, and I might be more inclined to agree with that, but it still seems like it's not a 100% rule.

Re: Introducing unlimited private repositories

#379
post #378

Earlier quoted context omitted.

You shouldn't be keeping api keys or other sensitive information in git at all . And please note -- if you do remove it from git, it will be available in your git history so that needs to be taken care of as well (should the repo ever become public -- a common "exploit").

Git is just a format for storing data with a record of how that data changed. Saying you shouldn't store it in git seems rather like saying you shouldn't store it in btrfs. It's true that if your btrfs disk image becomes public, the data is recoverable, and it's hard to reliably scrub deleted files from btrfs, but that doesn't mean it's the wrong tool for a filesystem (or a repo) that stays entirely internal. Saying…

> Saying that you shouldn't keep it on GitHub is different

I'd be willing to argue about that, but for my newrelic api key, a private github repo is sufficiently safe - even if I'd prefer if nobody starts having his servers report to my account.

Re: Introducing unlimited private repositories

#380
post #247

I find it interesting that so many people here are unhappy with the change. Sure, prices will go up for a lot of organizations, but is $9/worker/month really a lot to pay for all the stuff GitHub offers? At Bay Area prices isn't that about 5 minutes of developer pay per month? For independent use it seems like a very positive change, in fact I'm guessing it's a direct challenge to GitLab. I was considering moving my…

But you do know that it's not bay area only right? Millions of people outside US use it and the price difference is a lot to bear for some of them.
Post reply on HN