Not a page for Google. Posts for the people already following you.
PushToPost watches your pushes, PRs and releases, scores each one out of ten, and turns the ones that clear your threshold into posts on X, LinkedIn, Bluesky and Discord. It also publishes a hosted public changelog with JSON-LD structured data, pitched at getting cited by ChatGPT, Perplexity and Google AI Overview. Merge & Tell starts later in your git history and goes narrower. One trigger, the merge, and the full diff behind it. We overlap on native publishing and diverge at both ends: what we read, and what we publish to.
The short answer
Two real differences
And neither of them is a feature-list difference.
The first is what gets read. PushToPost’s own docs are clear: it reads commit messages and file change summaries, additions and deletions, and it does not clone your repository or read your source. Merge & Tell reads the diff. That is a deliberate trade on their side and I understand why they made it. It is also the trade I refused, because a commit message is a claim about a change and a diff is the change.
The second is the destination. Their headline pairs social posts with an SEO changelog built to be quoted by answer engines. That second half is a discovery product. Mine is not. I emit a changelog feed in Atom and JSON so you can render it wherever your docs live, and my interest stops there. No hosted changelog page, no chasing AI Overview citations. If that is what you want, they built it and I did not. What my feed is.
Why the category matters
A push is the middle of your thinking
The empty calendar is a supply problem. Nobody wrote the post because nobody triggered anything, and the person who would have was reviewing the PR and fixing the deploy. Both products answer that the same way. Something in git fires, and the writing happens without anyone remembering to do it.
The interesting part is what counts as “something”. PushToPost fires on pushes. I fire on merges.
A push is noisier than a merge, and noisier in a specific way. It is the middle of your thinking. Six commits on a branch, three fixing the previous two, one of them the word “wip”. PushToPost handles that with a 1 to 10 score against a threshold you set, plus [skip-post], [no-post] and [silent] flags in commit messages. That is more control than most tools offer.
I took the other route. Merge is the moment the change became real, and it is already your own quality gate. Everything before it is drafting. Then the filter ladder runs on top: bot authors, lockfile churn, publish: never paths, a marketing:skip label, diffs under ten meaningful lines. Small survivors are held and flushed as one weekly roundup rather than trickling out alone. How the filter works.
The rules split by owner. The repo owns skip and path rules in its own .marketing.yml, so they live on the branch and get reviewed like code. The app owns voice, ICP, hashtags and destinations. A block in a PR body can make posting stricter, never looser. Their commit flags travel the same direction, and that is the right default for anything a text field can reach. Where each rule lives.
Side by side
Which tool does which job
| The job | PushToPost | Merge & Tell |
|---|---|---|
| What starts it | A git push, plus PRs and releases | A GitHub webhook, on merge |
| What it reads | Commit messages and file change summaries. Not your source | The diff of the merged pull request |
| Deciding something is not worth posting | A 1 to 10 importance score with a threshold you set | The filter ladder, before a draft exists |
| Turning one thing off | [skip-post], [no-post] or [silent] in a commit message | marketing:skip, publish: never paths, or a PR body block that can only tighten |
| Small changes | Fall below your threshold and are skipped | Held, then flushed as one weekly roundup |
| Social networks | X, LinkedIn, Bluesky, Discord | X, Bluesky, Mastodon, LinkedIn, Discord |
| Per-network copy | Optimized for each platform’s style and limits | Written per channel, to that network’s own limit |
| Public changelog | A hosted page with JSON-LD, RSS per repo, featured entries | An Atom and JSON feed. You render it |
| Answer-engine discovery | The pitch. Structured data aimed at being cited | Not a goal of mine |
| Who the copy is aimed at | Your project, as the model reads it | A stored ICP, applied to every draft |
| Who appears to be speaking | Your account | A named voice, brand or person, resolved per channel. Copy in a person’s voice never auto-publishes |
| Publishing | Drafts wait for approval, or auto-publish above a quality threshold | Approval by default, autopost per repository, on a queue with slots, a minimum gap, retries and a stop button |
| Where the tokens live | Not described on their site | Encrypted server-side. They never reach the browser |
| What it measures | Not described on their site | Kept-rate, how much of what it wrote you published without rewriting |
The changelog row is the one that should decide this for a lot of people. Read it before the rest.
Honesty
Where we genuinely overlap
More than I expected when I first read their site.
Both of us trigger off git, not off you opening an app. Both of us publish natively to real accounts instead of handing you text to paste. Both of us write per-network copy against real character limits rather than shipping one body four times. Both of us default to approval and let you switch automatic posting on once you trust it. Both of us let a developer kill a post from inside the workflow they are already in, them with a commit flag, me with a label or a path rule.
On four of five social networks we are aiming at the same square. If all you want is code lands, posts go out, natively, with a review step, either product does that. Pick on the two axes above instead.
Not us
When PushToPost is the right answer
I would rather say this here than in an email three weeks in.
- The changelog page is the point. If you want a hosted, indexable changelog with JSON-LD and per-repo RSS, aimed at being quoted by ChatGPT, Perplexity and Google AI Overview, they built that and I did not. My feed assumes you already have somewhere to put it, and this is what mine looks like rendered.
- You do not merge pull requests. Plenty of solo projects push straight to main. My trigger never fires for you, which makes this an easy call.
- You want a dial, not rules. One 1 to 10 threshold is less to maintain than a ladder plus a YAML file, and less to maintain is a real feature.
- You do not want a tool reading your code. They say plainly they do not clone your repo or read your source. I read the diff. If that is a line you will not cross, cross it toward them.
- Your networks are their four, and Mastodon means nothing to you.
- You want per-push pricing published up front, from nine dollars a month. Mine is per account, not per push.
None of that is a knock on the tool. It is a different job, and a tool that claims to do every job is lying about one of them.
Together
Running both
Split by surface, not by repository. Their changelog is your public, indexable record of what changed, which is what it was built to be. Merge & Tell takes social, where diff-level detail makes the post worth reading and the voice matters more than the schema. If you are rendering a feed yourself, the format notes and worked examples are here.
The risk is double posting, and it is avoidable. Point them at the changelog and leave their social connections off, or point me at a social set that excludes the accounts they own. A repository pointed at a set that does not exist publishes nothing here. It never falls back to everywhere. What I do with your tokens.
If you want to check any of this before believing me, the bottom of the home page is my own accounts, live, posting what this wrote about its own merges.
Merge is the moment it became real.
You were going to merge the PR anyway.