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

Introducing unlimited private repositories

github.com

Post reply on HN
Print view View original

581–590 of 662 posts

Re: Introducing unlimited private repositories

#581

Post by timdorr »

samrift wrote: post #400
gelatocar wrote: post #62

What about companies like Epic Games that have few repos but many users? With their 2 private UnrealEngine and UnrealTournament repos they would have been paying $25 a month and under the new pricing structure will have to pay $815,913 per month... edit: That's based on what I can see as a UE4 subscriber, 2 private repos and 90657 users.

We are a small shop that has 4 repositories and 36 users (over half the company). About 10 of those users actually contribute code, the others are monitoring issues, pulling code just to run tests or create distributions, or bots. If we accidentally hit the upgrade button (we won't), our cost would go from 300/year to 3,648/year. Since only a small number of projects are on github - we use TFS for our main project an…

Hopefully, GitHub can adopt a similar "non-human user" account concept as Slack has. They are free to add and don't log into the normal applications.

Of course, do you really need full accounts for those purposes? Their APIs are really extensive and should give you access to set up things like CI and notifications.

Re: Introducing unlimited private repositories

#582

Post by OJFord »

fps wrote: post #269
cstejerean wrote: post #171

Earlier quoted context omitted.

Per user pricing makes a lot more sense than per repo pricing. This way larger organizations pay more money than smaller ones regardless of how they structure their code. This is a good deal for small organizations that like to have many small repositories (for internal libraries, utilities, micro services, modules, etc). Sure, it screws up a few models that rely on external collaborators to get access to private rep…

I work for a non-profit open source organization that collaborates on github ( https://github.com/edx/ ) We have lots of people who aren't employees, but have signed a contributor agreement with our organization and contribute changes to our software. Our bill will go up from $200/month to over $2000/month with this new pricing. We can afford it (it's still a small fraction of our AWS bill) but it will force us to lo…

At that scale of developers and cost, surely it makes sense to host your own instance of, say, GitLab?

Especially as you note AWS costs are much more - I'd have thought it would be much more economical to consolidate into AWS and run a VC server there.. but I'm not trying to tell you what's good for you, I'm just a guy with no experience of responsibility for things at that scale who's curious ;)

Re: Introducing unlimited private repositories

#583

Post by ak4g »

marssaxman wrote: post #573
qudat wrote: post #563

Earlier quoted context omitted.

These services are not the same, not since I last checked. Someone forks your repo, makes a change and then submits a PR. I can't pull their changes down until they give me read access to their forked repo. I found a lot of these little annoyances to be a big reason to switch to github. Not to mention their UI pales in comparison to github, which I think says a lot.

I've never understood why all the fork/change/commit/push/pull-request fol-de-rol is necessary. Why can't we just pull, hack, and submit a "push request"? But I guess I've never understood why everyone else seems to be OK with a build/repo system where it is even possible to break the build at all; it's always seemed to me like it should be set up so you push to a testing stage, which merges to master if the build su…

It's not necessary, it's a waste of development time and easily the biggest big-picture collective failure of our software engineering profession of the last decade. It easily beats out anything from the $foo.js world and the ongoing low-level security nightmare of web application development, because git, and more importantly, unnecessarily complex and error-prone git workflows have seen adoption across all kinds of software. There are probably a dozen projects in the world (the kernel admittedly being one of them) that are justifiably a good fit for the complex git-native workflows that have become standard practice across the industry today.

But if you're doing it the old-fashioned way, you might as well use Subversion. Or mercurial, if you want all the local history, with the added bonus that unlike git it sensibly keeps the least-surprise semantics of 'commit', 'revert', and other commands that merely have a 30-year history of expectations that held true prior to git. But Mercurial was not authored by Linus, nor does it have the impenetrable, otherworldly data model that a first-time version-control-system author would unavoidably end up concocting in scratching their itch without consulting the existing, completely satisfactory, solutions that served us well for decades, which greatly reduces the number of interesting topics you can blog about for Mercurial.

And so, git sees the adoption, github gets the $2bil valuation, and even bitbucket ends up switching to git as it's default. It won.

Software engineering, collectively, has a lot of maturing to do.

Re: Introducing unlimited private repositories

#584

Post by OJFord »

marssaxman wrote: post #573
qudat wrote: post #563

Earlier quoted context omitted.

These services are not the same, not since I last checked. Someone forks your repo, makes a change and then submits a PR. I can't pull their changes down until they give me read access to their forked repo. I found a lot of these little annoyances to be a big reason to switch to github. Not to mention their UI pales in comparison to github, which I think says a lot.

I've never understood why all the fork/change/commit/push/pull-request fol-de-rol is necessary. Why can't we just pull, hack, and submit a "push request"? But I guess I've never understood why everyone else seems to be OK with a build/repo system where it is even possible to break the build at all; it's always seemed to me like it should be set up so you push to a testing stage, which merges to master if the build su…

I agree, especially when all you really want to do is make a small change. (I'm less likely to contribute then - preferring to open an issue and nag someone on the team/who already has a fork to implement my one-liner!)

But I think it would be look pretty radically different architecturally - where would such a 'push request' live? You don't have push rights on the repo; nor do you have your own fork.

It needs to work in a Gitty-way - if not GH would anger far more people than one-line contributors. And Git needs access to a repo to which to push.

I suppose a fairly nice solution might be something like: - clone - edit - push --set-upstream origin gh-pr-

Github could then respond by mocking push-rights for the repo, but really creating a new 'hidden' repo; and mirroring commits on that branch to a PR opened on the original repo (to which you don't actually have anything beyond read-access).

When the PR merged they could delete the 'stealth repo'; of course if you wanted to maintain your own fork it could still work the way in which it does today.

Re: Introducing unlimited private repositories

#585

Post by rdancer »

geofft wrote: post #569
rdancer wrote: post #558

Earlier quoted context omitted.

TPM. It's just one role, but multiple users.

Do you have any tools you recommend for that? I love TPMs, but this seems wildly impractical for a small project with developers who aren't excited about becoming TPM experts. Also, does this rule out hosting on clouds that don't offer vTPM support? (Are there any that do ?)

There are dedicated discrete HSMs that can be installed. That's what I would do. Or, rather, wouldn't. I agree with you that it would be very impractical, unless the platform has a first-class API:

Chrome OS uses TPM heavily[1], and iOS has the Security Enclave. The standard TPM API is PKCS#11, so any hardware that speaks it can be used with any software that speaks it.

Problem with TPM is that the whole hardware and software stack needs to be secure, which in practice means it needs to be designed top-down with awareness of the TPM, and audited. The secrets must not be cached, written to file system, kept in memory, leaked over network. There are implementations such as Trousers[2], but it's more or less just a proof of concept; it may provide additional security, but most likely you're just using a very complex lock, and leaving the key under the mat.

[1] https://www.chromium.org/developers/design-documents/tpm-usa... [2] http://trousers.sourceforge.net/man/tpmtoken_setpasswd.1.htm...

Re: Introducing unlimited private repositories

#586

Post by hrez »

parsnips wrote: post #535
NetStrikeForce wrote: post #473

Earlier quoted context omitted.

I guess he's not paying his employees 900% market rate, why would he pay 900% market rate for GitHub instead of BitBucket? Just trying to point that your logic doesn't check out. I personally like the new pricing, but as a non-paying user of GitHub and BitBucket... I'll stick to BitBucket for my private repos :) I guess they don't give a damn as I'm still not paying either :)

You believe bitbucket represents the market?

Market (feature set requirements) is different for everybody. If bitbucket's features are enough for me to migrate off github it's absolutely market. 9 times cheaper at that.

Re: Introducing unlimited private repositories

#587

Post by skywhopper »

hunvreus wrote: post #130

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…

40 times as much in our case. But sounds like they aren't forcing it on us right away.

Re: Introducing unlimited private repositories

#588

Post by [deleted] »

taytus wrote: post #492
emidln wrote: post #439

Earlier quoted context omitted.

I've used Bitbucket in the past. They charge per-user[1], and their pricing is significantly better free for 5 users and then once you eclipse 5 users it's $1/user up to 100 users and then $200 for unlimited users. [1] - https://bitbucket.org/product/pricing

This. I use bitbucket too and I can't understand why people are still paying github when bitbucket does exactly the same and is free.

[deleted]

Re: Introducing unlimited private repositories

#590

Post by tokenizerrr »

guelo wrote: post #567
tokenizerrr wrote: post #537

Earlier quoted context omitted.

I use bitbucket at work, and it has many of the same features as github. The UI is a bit clunkier, and it does lack some of the flashy features such as automatically squashing commits when merging a pull request. However it does work fine, and it is well integrated with atlassian's other offerings which we also use. Mainly JIRA and hipchat, though bitbucket also has a per-repository issue tracker.

An aside, but I hate that squash feature more and more each day at my job.

Could you elaborate? Is it used for every pull request? That would be annoying, but sometimes developer leaves a trail of "work in progress" commits, so I'll wind up squashing those anyway.
Post reply on HN