Closing Issues via Commit Messages
github.com
github.com
Also, while I'm at it, support@github.com claims that "fixes otheruser/remoterepo#800" when merged into otheruser/remoterepo's default branch is not supposed to be marked as fixed. wtf?
And no, I am not going to email you a video showing a bug on your site.
I have my default branch set to 'dev' so that that's where pull requests go by default (otherwise I end up with pull requests going to 'master', and having to manually merge them). However, I'd like the github project page to default to 'master', and I'd also only like issues closed when they're merged into 'master'.
I guess what I'm asking for is more granularity in the default branch settings: I'd like a 'default branch' and a 'default branch for pull requests'.
It sure is convenient though.
Syntax & Setup: http://help.sprint.ly/knowledgebase/articles/108134-setting-...
Pre Commit Hook: https://github.com/nextbigsoundinc/Sprintly-GitHub
Now issues are not closed until the commit is marged into the default branch.
Please let us have unlimited private repositories for single user repos.
I'm a freelancer and would like to use Github for both personal (which I can open source) and commercial (I can't share the source) projects.
Currently your pricing scheme is borked. I can 7$ a month for only 5 repositories. That's insanely expensive for such a small repository with MINIMAL traffic in an out.
Remember: I'm the only one commiting code here, it's a freelance gig.
Should you offer this feature of free private repositories, you'll become my sole off-site code backup. BitBucket offers free unlimited with a limit of 5 contributors per repo. If they can do it, why can't you?
I understand your plight, I've asked GitHub similar questions before and they were very gracious.
But the simple fact is, and let's talk frankly as developers here, customers are overhead. Most of the time I really enjoy working with my customers, and we get along great, but at the end of the day if the checks stop coming I'm going to stop working for them.
You see, you're thinking about this from a "but it's only 200KB of text files sitting on S3, why does it cost so much?"
But GitHub sees your proposal as another customer relationship to maintain. Customer relationships are expensive and require investment. They require support staff to answer emails. They require expensive on-call devops to be paged in the middle of the night when some random fileserver (maybe even the one with your minimally trafficked repos) stops responding. GitHub's business model isn't eyeballs, it's dollars, and your proposal doesn't bring them dollars.
Disclaimer: I work for Atlassian and we run BitBucket.
If you meant the disclaimer, then yes - just being honest about who feeds me :)
If this is the case, you should not need to continue commenting, since it is likely that they have already seen your previous comments.
You should contact Github directly - https://github.com/contact - instead of posting off-topic screeds on Hacker News.
It can also do the reverse, pull the archives down, create a new private repo and push everything back up.
It works quite well, and certainly solved the problem of hitting that ceiling.
Really, help me, I want to understand— but you sound like a crazy person.
Heroku only integrates well with Github (for some stupid reason) and I would prefer to host it on Github for my comfort.
I'm located in Bolivia. I do not charge 4000$ per project. My cost of living is lower, hence, my rates are lower than most first world country programmers. There's your reason why I can't afford Github's ridiculous prices.
I understand cost of living differences, but what are you charging that $2/mo makes an impact?
And if finances are really that tight, how do you get away with using Heroku?
The silly thing here is that Github's pricing for private repos doesn't take into account bandwidth use or repo size. After all, those are the costs to Github, not number of repos. It would be like a grocery store charging you a flat fee for 5 items, without bothering to inquire about what those items were.
[2] You have to have somewhere to host it, and that hardware, power and bandwidth cost money. If you already have a server of some sort -- like a cheap Xen VPS, or an older machine that you use as a Linux server that runs 24/7 stuffed in a closet in your house -- you can treat that part as a sunk cost, since you would have bought it regardless of your adoption of Gitlab.
[3] You have to go through the trouble of setting it up and keeping it up-to-date yourself. Saying it's "free" assumes the time you spend creating and maintaining the installation doesn't cost you anything.