Not a page for Google. Posts for the people already following you.

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. I ship a public HTML changelog with JSON-LD too, plus Atom and JSON feeds of the same entries. Their pages live at /changelog/username/repo. Mine live at a UUID that acts as a capability, so they are public once you share them and unlisted until you do. What the pages and feeds are.

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. Under ten meaningful lines the diff counts as trivial, and a three-line fix the brief calls major can still post. Chores, refactors and the smaller user-facing news skip. Nothing posts them. I batch by hand when I want the pile. 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 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 this one

When PushToPost is the right answer

I would rather say this here than in an email three weeks in.

• You want a guessable changelog URL. Their pages live at /changelog/username/repo. Mine use an account UUID that acts as a capability, so the page is unlisted rather than guessable, and nothing in the URL says your product name. If that shape is the point, they built it. 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 priced per draft, not per push. Starter is 40 drafts a month for $29.

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 URLs are named after the repo, which is what they were 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 wiring 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.

Questions

Short answers