After a couple of experiments, the strategy I settled on for qpp:

1. use the github auto-generator to create a github-ish looking site on (disconnected) gh-pages site,
2. copy the gh-pages files onto master, without changing their relative paths,
3. delete the local gh-pages, branch master on to gh-pages, force push gh-pages,
4. edit the site pages on master, test on local server, push as a regular commit on master,
5. publish by merging master onto gh-pages, allowing fast-forward only.

This avoids any duplicate code / testing / sync problems. The only minor issues: the site must be edited without the github tools and you can't change themes without starting over on the site.

Since the amount of files we will have on gh-pages I don't mind having these on master.

Another issue is that we have been starting to use npm install to manage dependencies. I don't think this will work with gh-pages. Maybe we need to go back to git submodules?

I use 'fake' git submodules: clone on one machine and commit the
subdirectory. git ignores the .git. All clones get copies of the
dependencies and never need to think about them (incl gh-pages branch). To
update a dependent, remove and re-clone the subdirectory.

Another soln: rebase gh-pages on master, npm install, commit dependents on
gh-pages, force push gh-pages. Or just let gh-pages history include merges.

On Thu, Mar 28, 2013 at 9:26 AM, Erik Arvidsson notifications@github.comwrote:

Since the amount of files we will have on gh-pages I don't mind having
these on master.

Another issue is that we have been starting to use npm install to manage
dependencies. I don't think this will work with gh-pages. Maybe we need to
go back to git submodules?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/220#issuecomment-15598360
.

Committing node_modules to the gh-pages branch seems acceptable.

On Thu, Mar 28, 2013 at 12:40 PM, johnjbarton notifications@github.comwrote:

I use 'fake' git submodules: clone on one machine and commit the
subdirectory. git ignores the .git. All clones get copies of the
dependencies and never need to think about them (incl gh-pages branch). To
update a dependent, remove and re-clone the subdirectory.

Another soln: rebase gh-pages on master, npm install, commit dependents on
gh-pages, force push gh-pages. Or just let gh-pages history include
merges.

On Thu, Mar 28, 2013 at 9:26 AM, Erik Arvidsson notifications@github.comwrote:

Since the amount of files we will have on gh-pages I don't mind having
these on master.

Another issue is that we have been starting to use npm install to manage
dependencies. I don't think this will work with gh-pages. Maybe we need
to
go back to git submodules?

—
Reply to this email directly or view it on GitHub<
https://github.com/google/traceur-compiler/issues/220#issuecomment-15598360>

.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/220#issuecomment-15599269
.

erik

https://github.com/google/traceur-compiler/settings > Automatic Page
Generator
Drop some text for the home page and pick a theme.

jjb

On Thu, Mar 28, 2013 at 9:51 AM, Erik Arvidsson notifications@github.comwrote:

Committing node_modules to the gh-pages branch seems acceptable.

On Thu, Mar 28, 2013 at 12:40 PM, johnjbarton notifications@github.comwrote:

I use 'fake' git submodules: clone on one machine and commit the
subdirectory. git ignores the .git. All clones get copies of the
dependencies and never need to think about them (incl gh-pages branch).
To
update a dependent, remove and re-clone the subdirectory.

Another soln: rebase gh-pages on master, npm install, commit dependents
on
gh-pages, force push gh-pages. Or just let gh-pages history include
merges.

On Thu, Mar 28, 2013 at 9:26 AM, Erik Arvidsson <
notifications@github.com>wrote:

Since the amount of files we will have on gh-pages I don't mind having
these on master.

Another issue is that we have been starting to use npm install to
manage
dependencies. I don't think this will work with gh-pages. Maybe we
need
to
go back to git submodules?

—
Reply to this email directly or view it on GitHub<

https://github.com/google/traceur-compiler/issues/220#issuecomment-15598360>

.

—
Reply to this email directly or view it on GitHub<
https://github.com/google/traceur-compiler/issues/220#issuecomment-15599269>

.

erik

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/220#issuecomment-15599935
.

If the goal is to run the html tests live on the site, here is something
that seems to work:

http://usrbincc.github.com/traceur-compiler/

But if you just want the demos, all you have to do is put up an index
page, and master should work as-is.

Note that the closure-library url change should persist through
git merge master, modulo any merge conflicts.

Sorry, not too much experience with gh-pages, so I can't speak to the
issues johnjbarton was referring to. Does it have to be an orphan branch
in order to work with the page-building tools? Or is it something else?

On Fri, Mar 29, 2013 at 9:33 AM, usrbincc notifications@github.com wrote:

If the goal is to run the html tests live on the site, here is something
that seems to work:

http://usrbincc.github.com/traceur-compiler/

But if you just want the demos, all you have to do is put up an index
page, and master should work as-is.

Yes, that is what I am suggesting.

Note that the closure-library url change should persist through

git merge master, modulo any merge conflicts.

Sorry, not too much experience with gh-pages, so I can't speak to the
issues johnjbarton was referring to. Does it have to be an orphan branch
in order to work with the page-building tools? Or is it something else?

The automatic tools from github do two things:

1. auto-create a nice githhub-ish site based on a selected theme,
2. put the result in an orphan branch.
   But once you use the auto tools you can copy the site files on to master
   and replace the gh-pages branch with a branch from master.

The gh-pages server only seems to need the branch to be named "gh-pages"
and to have an index.html at top level.

All I really care about is being able to link to the demos.

I guess we can use the default index.html to get started. I don't really care much about having a nice landing page at this point.

If the auto-tools don't let you edit and preview live (hard to tell for sure
from what you're saying), that makes them a lot less interesting. I probably
need to create a test repo just to play around with this.

I found out something interesting (scroll down to "Templating using Markdown"):

http://xlson.com/2010/11/09/getting-started-with-github-pages.html

I created a file 'markdown-test.markdown' on my gh-pages branch, which
translates into either of these URLs.

http://usrbincc.github.com/traceur-compiler/markdown-test.html
http://usrbincc.github.com/traceur-compiler/markdown-test

For some reason, the title doesn't show up as promised on the site. But the info
is from 2010, so maybe it's out of date. No time to investigate further.

git checkout master -b gh-pages

{ printf "---\ntitle: %s\n---\n\n# %s\n\n" traceur traceur
  find demo example test -name \*.html | \
    xargs -I_x printf "* [%s](%s)\n" _x _x
} > index.markdown

git add index.markdown
git commit -m 'Added index.markdown'

## You only have to do this the first time; after that, you
## can just do a 'git push'.
git push origin gh-pages

## That's how long you have to wait at first.
sleep 600 && echo ready!

I still prefer html for the flexibility, not to mention the ability to use JS
and of course, traceur in-page.

Feel free to use this simple index page, if you want:

{
cat <<"END"
<!doctype html>
<html>
<head>
<title>traceur-compiler</title>
<style>body{font-family: monospace;}</style>
</head>
<body>
END

find demo example test -name \*.html | \
  awk '{printf("<div><a href=\"%s\">%s</a></div>\n", $0, $0)}'

cat <<"END"
</body>
</html>
END
} > index.html