A lot of room for refinement as well as constraints in terms of what kinds of PRs are allowed etc, but the basic workflow works.
You will need to create a Github Personal Access Token
Demo: TiddlyWiki — a non-linear personal web notebook
Background: Edit documentation in TW and use Github API to create PRs directly?
This is the direct link for creating a new token with the minimum scope:
Requires signing in to Github.
Be aware! The token will only be shown once when it is created.
You basically can create a new token for every PR, which imo is a bit cumbersome. Or you give it an expiration date eg: 1 week or 1 month. So you will be sure nobody else can use them for long.
If you give your access tokens a “speaking” name, they are easy to identify if you want to delete them. So make sure, you delete the right one 
@pmario since you have just tested this PR creation process from TW a fair bit, perhaps you could share your impressions with others when you get the chance?
It is OK to create PRs for testing purposes.
They will only be created against my fork of the TiddlyWiki repository, which I can just delete and recreate later to clean up. I have had two different private messages about this so I figured I should post about it here.
If they’re only created against your fork, why am I seeing them on Jermolene/TiddlyWiki5 ?
It’s alarming, but hopefully safe? I’ve never pushed to someone else’s fork of the project before.
It’s amazing what you’ve put together in such a short time.
I used the same name for both PR pushes, but they created two different PR’s. So either we need to be able to specify a branch, or have the changes pushed to a specified existing PR.
GitHub knows that you have forks/branches that could apply to the upstream project.
Git is structured to be able to make this work with its internal structure.
eg I might maintain a “Fission fork” and any branches there — from “main” to “Boris-minor-tweak” — could equally be applied “upstream” to the TW5 core.
As Boris mentions, that is just Github trying to being helpful, and knowing that Jeremy’s repository is the parent and you have a branch with new changes, it is suggesting to create a PR. If you check back later (tomorrow perhaps?) you wont see those messages any more.
Updating the same PR is not implemented at the moment, but it is possible but will require a bit more work. This is how far I got with missing my bed time by a couple of hours last night! @pmario and I have been discussing what it would take to also be able to update a PR over in the other thread: Edit documentation in TW and use Github API to create PRs directly? - #14 by saqimtiaz
Personally I think it would be helpful to figure out this part of the user story and workflow first, creating a new PR and how and where the user starts with a copy of tw-com. Updating PRs can come in time. The UI needs work as well and that is all wikitext work.
Hopefully there is enough there at present to inspire others to contribute towards getting this usable by others.
When I’m doing this by hand, I make changes to a branch I’ve created. Pushing the branch adds it to the current PR associated with the branch. Well, at least I thought that was what is happening.
@Mark_S understood and the process is the same, it just isn’t implemented at present and will need more work.
Getting it working so quickly meant taking a shortcut with a plugin (createPullRequest) for the base library (octokit) that works with the API. This plugin creates new PRs and makes that very easy, but abstracts away pushing to a branch so pushing to an existing branch needs to be handled directly with the low level API. As I mentioned, we have been discussing this in the other thread if you are interested in further details.
I have pushed through some quick changes, hopefully I haven’t broken anything.
I have been spending time on this that I really do not have to spare at present, so it is my hope that others will chip in to get this to a state where it is usable.
The code itself is very concise and not complex.
Changes:
.tid extensionNote that the first time you create a PR after loading the wiki, the Octokit library is loaded on demand. This is why that first PR takes longer, a second PR created without reloading the wiki is much faster. This is implemented in this manner so that wikis that have this “plugin” do not load the libraries from the CDN until and unless they need it. If we imagined an edition that was specifically for making PRs, the libraries could also be loaded when the wiki loads.
Demo link updated with one that updates with the latest content from tw-com every 15 minutes.
I’ve submitted my first PR to jermolene using this system. It probably has the longest branch name of any PR ever created.
It might make sense to limit the slug generated for the branch name to a max length, lest we run in to some invisible limit.
@saqimtiaz Is the demo page supposed to be fairly up-to-date? I was looking at the EditTextWidget tiddler and noticing that it predates the tiddler at TiddlyWiki .com, which was updated Oct 21.
Thanks!
It runs off the master branch which corresponds to the pre-release for TW. Currently the tiddlywiki-com branch - which is what corresponds to the tiddlywiki.com site - has changes that the master does not. @jeremyruston could we merge please?
For working on current documentation using the tiddlywiki-com branch would make more sense, and that would need a slightly different build process. I can switch that over when I find the opportunity to work on this.
One consequence for making that switch will be that it will no longer be possible to work on pre-release documentation using the same setup, though that should be a less frequent need.