| 21:45 | <shu> | ljharb: what's the preferred way to publish rendered specs in proposal repos? |
| 21:45 | <shu> | a branch or a subdir? |
| 21:46 | <Michael Ficarra> | definitely a gh-pages branch |
| 21:46 | <ljharb> | there isn't consensus. the template i built does neither, it auto-publishes to the root |
| 21:46 | <ljharb> | michael and some others prefer a separate gh-pages branch |
| 21:46 | <shu> | i don't really care, i just want the least amount of work possible |
| 21:46 | <shu> | i didn't know it could just use a single file? |
| 21:46 | <ljharb> | it can |
| 21:47 | <ljharb> | you can make a proposal repo from the template for the "root" approach |
| 21:47 | <shu> | oh i see, you can just serve the entire root directory |
| 21:47 | <ljharb> | yep |
| 21:48 | <ljharb> | the pros of this approach are that you can switch commits to specific ecmarkup and the rendered html is largely right there. cons are that the commit history will be slightly more crowded. |
| 21:51 | <Michael Ficarra> | reviewing PRs becomes annoying |
| 22:07 | <shu> | how so? |
| 22:08 | <Michael Ficarra> | the built spec HTML changes are mixed in with the source spec ecmarkup changes |
| 22:08 | <shu> | ah, when i used a subdir i always just push another commit called "Update render" or the like |
| 22:12 | <bakkot> | that gets annoying when there's multiple commits though |
| 22:12 | <bakkot> | strongly prefer the approach the spec takes, where there's a different branch with the rendered spec and you never have to think about it |
| 22:13 | <bakkot> | you can use https://github.com/tc39/template-for-proposals/pull/32 as a basis for this and then never think about it; commits to the main branch will automatically update the gh-pages branch |
| 22:26 | <shu> | wfm |
| 22:43 | <ljharb> | .gitattributes auto-collapses the diff in the PR for the HTML changes |