Introducing unlimited private repositories • Hacker News Board

Re: Introducing unlimited private repositories

#391

Post by WorldMaker » Wed, May 11, 2016, 2:45 PM UTC

therealmarv wrote: post #228

me_bx wrote: post #133

Earlier quoted context omitted.

He probably means in terms of general usability. This is the reason why I don't use bitbucket at all, and I'm happy to give some money to github in exchange for their service. Bitbucket's issue tracker is such a pain to work with. I remember being redirected to a new page whenever I had to create a new tag. Then I'd loose the content of the issue I had started to write, something like that.

you are doing it wrong. If you want issue management you will buy Jira from the same company which is superior to github. Bitbucket is one tool of many for Atlassian.

Isn't that the problem, though? GitHub has one Issue tracker that is "good enough" for most projects I've worked on, and gets better over time because GitHub dog foods it (even if they don't always see some of the large open projects issues with it). Bitbucket has two Issue trackers, a "sort of useful" minimalist one that is worse than GitHub's and an upsell to Jira which is maximalist overkill for any project I've worked on. Atlassian doesn't have much incentive to make Bitbucket's issue tracker any better than it's current "almost decent" because it wants to upsell Jira. You can pretty much assume that Atlassian only works in Jira themselves.

(Similarly, VS Team Services has only one issue tracker and I'd rather use that than both of Atlassian's offerings, even though it's almost equally maximalist with Jira, mostly because they clearly dog food it and don't try to upsell into it from a worse system that nobody wants to use.)

Re: Introducing unlimited private repositories

#392

Post by Xylakant » Wed, May 11, 2016, 2:46 PM UTC

uxp wrote: post #387

Xylakant wrote: post #373

Earlier quoted context omitted.

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?

The newfangled approach is something like HashiCorp's Vault, which is a dream when you're looking at more than half a dozen systems with similar roles. A different approach that I like to use for single or smaller cluster systems is Ansible's Vault and rolling out config files based on templates per environment. All actual config files are gitignored so I don't have do deal with conflicts on the server if I use a git…

I'm aware of the implications concerning the history, but sorry, the machine park is two machines. Setting up vault would just be total overkill. The people that have access to that repo change like once every few years. The repo will never go public. Let's keep the solution at least somewhat tailored to the problem.

Re: Introducing unlimited private repositories

#393

Post by woah » Wed, May 11, 2016, 2:48 PM UTC

fps wrote: post #278

jnmandal wrote: post #270

Earlier quoted context omitted.

If you are non profit and open source do you really need private repos?

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.

What kind of bad things will happen if people are able to see what you are doing?

Re: Introducing unlimited private repositories

#394

Post by Xylakant » Wed, May 11, 2016, 2:48 PM UTC

neoeldex wrote: post #390

geofft wrote: post #378

Earlier quoted context omitted.

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…

A git repo is usually shared over multiple machines/developers. So the chance of someone publicating it is larger. As well as the entire history is usually copied everywhere

Why would that be a general rule. I track my personal passwords in git (using pass). I'm the only person with access to that repo. I just like to have a history - and the convenient way of moving files around and merging changes.

Re: Introducing unlimited private repositories

#395

Post by sytse » Wed, May 11, 2016, 2:48 PM UTC

endymi0n wrote: post #191

asher_ wrote: post #183

Earlier quoted context omitted.

I couldn't agree more. It has annoyed me when companies charge more for decisions about how you choose to do something - in this case how you split up your code. Paying per person makes much more sense.

This was exactly the reason we used Bitbucket in the beginning, even if it was worse in some aspects. Github would have been simply too expensive (or restricting) with our "it's always in source control" approach, even for smaller prototypes. We're happy Gitlab users now by the way - and I'm curious how long Github will survive with their over-valuation as the alternatives get seriously better now - the lock-in and n…

Just wanted to add that if you don't want to run GitLab yourself our GitLab.com is free with unlimited private repositories but it also has also unlimited private collaborators https://about.gitlab.com/gitlab-com/

Re: Introducing unlimited private repositories

#396

Post by blktiger » Wed, May 11, 2016, 2:49 PM UTC

cstejerean wrote: post #171

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…

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…

If you want unlimited private repositories, just use bitbucket instead. It's free instead of $7 a month.

Re: Introducing unlimited private repositories

#397

Post by benbenolson » Wed, May 11, 2016, 2:50 PM UTC

This is just another reason to move to something like Gitlab or just self-host your Git repos. It takes literally seconds to set up your own Git server, so why not?

Re: Introducing unlimited private repositories

#398

Post by BinaryIdiot » Wed, May 11, 2016, 2:50 PM UTC

therealmarv wrote: post #238

It seems most users here don't have gitlab.com in their radar and only mentioning Bitbucket as competitor. I've recently switched all my private personal repos to gitlab.com which also allows unlimited private repositories because gitlab.com seems to have better UI and more features than Bitbucket (when not buying any additional Atlassian Jira etc. products).

For all of my personal projects I use GitLab. It has about the same amount of features as GitHub (more in many areas, in fact) and it's free for most usage, even private.

GitLab and BitBucket are going to eat GitHub's lunch if they don't change this crazy pricing model.

Re: Introducing unlimited private repositories

#399

Post by woah » Wed, May 11, 2016, 2:50 PM UTC

Xylakant wrote: post #373

cloverich wrote: post #316

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

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?

What the hell? Are you defending a decision to keep keys unencrypted in a git repo?

Re: Introducing unlimited private repositories

#400

Post by samrift » Wed, May 11, 2016, 2:51 PM UTC

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 and github for tools - its just a non-starter.

Heck, 5 "bot accounts" is $540/year to support CI builds and slack notifications. Yikes! More than we pay now.

It seems like the only shop that would save money would be the little in-house development departments with 5 people and tons of projects. However, even there they would probably forego using issues tracking in github because of the extra user cost.

I would be very interested to see real stats on how many orgs actually "upgrade" to this new more expensive pricing model vs how many stay with the more sane model. The real losers are orgs that can't sign up under the old model. The real winners will be the github alternatives (gitlab, bitbucket, etc) that can use this as an opportunity to grow user base.