On Tue, Jan 27, 2015 at 11:50 PM, Patrick H. Lauke <redux@splintered.co.uk> wrote: > On 27/01/2015 14:32, Rick Byers wrote: > > From what I've been able to figure out, gh-pages is triggered either by >> a branch name or a special repo name (eg. >> https://github.com/RByers/rbyers.github.io has just a master branch). >> It looks like the manifest spec <https://github.com/w3c/manifest> is >> using only a gh-pages branch, so presumably that's an acceptable >> workflow. As long as we're iterating on two different branches then >> gh-pages isn't an option for us. Perhaps we should move the TEE to a >> new document in the same branch as v1-errata? >> > > The latter is basically what I'm doing with most of my stuff...on master, > make a branch gh-pages, then set THAT in github to be the default branch, > and delete the master branch. Job done. Any change, merged PR, etc will > almost instantly update the live version (see for instance > https://github.com/patrickhlauke/touch/ which only has gh-pages, > immediately accessible from http://patrickhlauke.github.io/touch/) Let me experiment a bit on what is possible and see what I can come up with. Having a master branch that is bitrot isn't nice, and having no master and only gh-pages triggers funny behavior in some tools, which isn't ideal. (If memory serves, quite a few tools assume master is there.) Quickest solution that came to mind is to have a gh-pages branch which has two dummy documents triggering redirects to a rawgit.com URL. -- Sangwhan Moon [Opera Software ASA] Software Engineer | Tokyo, Japan
Received on Wednesday, 28 January 2015 06:05:56 UTC