Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Figure out the /docs situation? #2

Open
cmyr opened this issue Dec 31, 2018 · 5 comments
Open

Figure out the /docs situation? #2

cmyr opened this issue Dec 31, 2018 · 5 comments

Comments

@cmyr
Copy link
Member

cmyr commented Dec 31, 2018

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.

@Cogitri
Copy link
Member

Cogitri commented Mar 3, 2019

Hum, couldn't you deploy the docs to this repo via Travis?

@cmyr
Copy link
Member Author

cmyr commented Mar 9, 2019

Probably, it just needs to actually get done. 😁

@Cogitri
Copy link
Member

Cogitri commented Mar 9, 2019

I can look into that, doing something similiar for gxi

@ryanbloom
Copy link
Collaborator

ryanbloom commented Mar 9, 2019

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.

@Cogitri
Copy link
Member

Cogitri commented Mar 10, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants