[Buetol]

Just see the top requested features: https://github.com/isaacs/github/issues?q=is%3Aissue+is%3Aop...

* Change the target branch of a pull request pull-requests

* Delete / remove an issue completely.

* Gist comments and mentions don't trigger notifications

* Add HTTPS support to Github Pages

* Add ability to follow organizations like a user

* Insert automatically generated table of contents TOC on rendered markdown files like README.md.

* pre { tab-size: 4 }

[beltex]

> Add HTTPS support to Github Pages

This is technically already available, though not officially documented anywhere [1]. Example [2]

[1] https://github.com/isaacs/github/issues/156#issuecomment-377...

[2] https://beltex.github.io

[holic]

While that's true, I think the discussion in that issue has gone more towards HTTPS support for custom domains.

[elithrar]

> While that's true, I think the discussion in that issue has gone more towards HTTPS support for custom domains.

A huge number of those "+1 for HTTPS on custom domains" don't seem to understand/appreciate the difference in providing HTTPS on the *.github.io (one wildcard cert) vs. HTTPS support for custom domains.

The latter would require an interface (UX being key here) and storage for uploading your own domain certificates to GitHub, which is nothing like any other part of GitHub right now. I also presume that most of these "+1's" would want this service to remain free.

[tracker1]

You could always use CloudFlare directly for that... I would presume that their underlying connection to Github is very close and reliable in terms of risk for MITM.

[kirushik]

Even better, you could CNAME your custom domain into the *.github.io domain, which is protected by a wildcard https.

So you traffic between CloudFlare and GitHub will also be secured.

[holic]

Last I checked, this doesn't actually work with the way *.github.io is set up.

[bigiain]

I wonder if letsencrypt will allow that to become practical?