5 ms·

Just see the top requested features: https://github.com/isaacs/github/issues?q=is%3Aissue+is%3Aopen+sort%3Acomments-desc https://github.com/isaacs/github/issues

by Buetol 11y ago

Just see the top requested features: https://github.com/isaacs/github/issues?q=is%3Aissue+is%3Aopen+sort%3Acomments-desc 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 11y ago
> 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-37747957 https://github.com/isaacs/github/issues/156#issuecomment-377... [2] https://beltex.github.io https://beltex.github.io
- holic 11y ago
  While that's true, I think the discussion in that issue has gone more towards HTTPS support for custom domains.
  - tracker1 11y ago
    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 11y ago
      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 11y ago
        Last I checked, this doesn't actually work with the way *.github.io is set up.
  - bigiain 11y ago
    I wonder if letsencrypt will allow that to become practical?
  - elithrar 11y ago
    > 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.

by Buetol 11y ago

beltex 11y ago

> 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-37747957 https://github.com/isaacs/github/issues/156#issuecomment-377... [2] https://beltex.github.io https://beltex.github.io

holic 11y ago
While that's true, I think the discussion in that issue has gone more towards HTTPS support for custom domains.
- tracker1 11y ago
  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 11y ago
    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 11y ago
      Last I checked, this doesn't actually work with the way *.github.io is set up.
- bigiain 11y ago
  I wonder if letsencrypt will allow that to become practical?
- elithrar 11y ago
  > 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.