Figure out the /docs situation?
cmyr opened this issue · 5 comments
Currently (afaik) the docs are duplicated between the xi-editor repo and this repo. It would be nice If this weren't the case, and ideally it would be nice if the general docs still lived in that repo, so that we could make it easier to verify that a PR that touches the protocol also updates the docs.
Not really sure what the best approach is, here, but wanted to at least be thinking about it.
Hum, couldn't you deploy the docs to this repo via Travis?
Probably, it just needs to actually get done. 😁
I can look into that, doing something similiar for gxi
I've working on the git-history side of this issue for the past few weeks; some of this may be helpful:
The easiest solution would be a script that repeatedly copies over the files from xi-editor/xi-editor. The main downside is that we'd have a bunch of automated "copy over docs" commits in the log.
A (possibly) better way is to have a site branch (which contains everything except the docs) and a docs branch (which is a replica of xi-editor/docs/docs). All pull requests go to the site branch; after a pull request is merged, we create a master branch by subtree-merging docs into site. The final website runs from master. That way the two commit histories stay separate except for a final merge commit. Here's a script that does roughly what I'm talking about. We'd need to do a force-push to master after each pull request, but I don't think it's a huge issue if no one is working off of that branch.
Another way is to keep committing on master. Then if there's a commit in xi-editor/docs/docs we'd subtree-rebase it (is that a thing?) onto master. I've had trouble getting this to work consistently though, and it might be harder to maintain. Maybe the previous option is more feasible?
As for where this is run, I was thinking it could just be done locally via a bash script for now, since the website isn't updated that frequently. But Travis could be worth looking into.
As for where this is run, I was thinking it could just be done locally via a bash script for now, since the website isn't updated that frequently. But Travis could be worth looking into.
FWIW, you can run bash scripts for deployment on Travis too, see https://github.com/Cogitri/gxi/blob/master/.travis.yml