You spot a typo in a post RankMill already sent to GitHub. Or you want to add a paragraph you forgot. You can fix it right there in RankMill. The app then tells you that the copy in your repo no longer matches. After that, you decide when the change goes out.
This post covers how that works for GitHub, which button you press, and why RankMill waits for you before it touches the pull request.
What going out means for a GitHub post
When a project publishes to GitHub, each finished post goes out as a pull request. RankMill works out where your repo keeps its posts. It writes the file there, opens the pull request and merges it.
A post can go out in three ways:
- You pressed Publish.
- It reached its scheduled time.
- The project publishes automatically.
The post counts as published when the pull request merges, not when it opens. That gap matters for edits. If GitHub refuses to merge, RankMill retries a few times and shows the reason in the app. So for a while, your post can sit in an open pull request that has not merged yet.
Keep those two states in mind: open and merged. They decide which update button you get later.
Editing a post that is already out
You edit a post that has gone out the same way you edit any other post. There are two ways to do it.
- Chat with the editor. Tell the editor agent what to change, in your own words. It makes the change straight away. Under its latest reply, each paragraph it changed shows up as a card with the old and new wording and an Undo button. Edit turns are free.
- Edit it yourself. Open the block editor and type. It saves as you go, so a one-word fix does not need an agent at all.
The post's version history keeps its newest hundred versions. If an edit goes wrong, you can put an older version back.
One thing to know: the auditor only reads finished posts that have not been published yet. It will not pick up problems in a post that is already out. Fixes to a live post come from you.
How RankMill tells you the copy is stale
Once you edit a post that has gone out, the app marks the published copy "Out of date".
That label means the post in RankMill and the post in your repo no longer match. The version in RankMill is the newer one. Your repo still holds the old one.
Nothing gets pushed while that label is there. You can keep editing. You can make three more changes, or leave it until tomorrow. Your repo only changes when you push the update.
Two ways to push the change
Which button you see depends on where the original pull request is.
While the pull request is still open: "Update pull request"
If the original pull request has not merged yet, you get "Update pull request". RankMill adds a commit to that same open pull request, with your new version of the post.
You end up with one pull request for the post. There is no second one to keep track of.
Here is when this can happen. Say GitHub refused to merge the pull request, and RankMill is still showing you the reason. You notice a mistake in the meantime. You fix it in RankMill and press "Update pull request", and the fix rides along in the same pull request.
After it has merged: "Open update pull request"
Once the original pull request has merged, it is done. There is nothing left to add a commit to. So instead you get "Open update pull request".
RankMill opens a new pull request with the changed post. Then it merges that one too, just like the first.
Your repo history then shows two pull requests for the post: the one that published it and the one that updated it. That is handy if you ever want to see what changed and when.
Why nothing updates a pull request on its own
RankMill does not send an update by itself. Saving an edit does not do it. The "Out of date" mark does not do it. Every update starts with you pressing the button.
That fits how the rest of RankMill works. It does not publish anything unless you press Publish, give a post a time, or switch on automatic publishing or Auto-schedule. It also does not touch your repository beyond the pull requests it opens for your posts. Updates follow the same idea: your repo changes when you say so.
In practice, this helps you in a few ways.
- You can batch your edits. Fix the typo, rewrite the intro, add an example. Then push once, instead of sending a stream of small commits.
- You can check before it goes out. A chat edit lands in the post straight away. You may want to read the result, or undo a card, before it reaches your repo.
- Your repo stays predictable. If you review what lands in your repo, or other people work in it too, nothing turns up that you did not ask for.
The flip side is simple. If you edit a live post and never press the button, your repo keeps the old version. The "Out of date" mark is there so you can see which posts still need pushing.
What it costs and where to check on it
Fixing a live post costs no credits. Edit turns are free. Editing the markdown yourself is free. Publishing and sending updates are free too.
Rewriting a finished post is different. That counts as a write, so it spends credits like any other write.
To see how an update went, open the project's Publishing tab. It lists everything the project has published or tried to, with its status, the latest error and a Retry button. The Activity page also lists GitHub publishes and updates as runs. Each one shows how long it took, and why it failed if it did.
A simple routine for live edits
When you want to change a post that has already gone out, this is the whole loop:
- Make your change, by chatting with the editor or by editing the post yourself.
- Read the post again. Undo any change you do not want, or restore an older version.
- Look for the "Out of date" mark on the published copy.
- Press "Update pull request" if the original is still open, or "Open update pull request" if it has merged.
- Check the Publishing tab to see it go through.
Here is the same routine at a glance.
Your edit stays in RankMill until you push it, and the "Out of date" mark shows you which posts are waiting. Push when you are happy with the post, not before.