Repository navigation
Superfluous "pull" notifications #639
Description
Since some days now I am getting doublicate, automated "pull" notifications, like here:
With avrdudes/avr-libc@eb5d341 I fixed and closed the bug.
Then some hours later I get a notification saying pull added a commit that references this issue xx hours ago
It says that the issue will be closed when avrdudes/avr-libc@eb5d341 will be integrated, bit that commit has already been done hours ago on the main branch!
This issue will close once commit eb5d341 is merged into the 'main' branch.
I am getting such confusing notifications also on other closed issues on the main branch.
Reacted by kitadai31, Ansar Smagul, Adil Hanney and Robert Dailey
Reacted by Adil Hanney
Activity
rcdailey commentedon Feb 26, 2026
Adding another data point. I maintain Recyclarr and today noticed
pull[bot]appearing in my issue timeline via a fork (aelfa/trash-updater) that uses this app. The commit had already been merged and the issue closed hours prior; the timeline entry is pure noise.I've read through #633, #619, #628, #625, #596, and #466. The maintainer's position in those threads is that this is a GitHub platform behavior and would happen regardless of Pull. That's technically true in the narrowest sense, but misleading in practice. Without Pull automatically syncing commits into forks that would otherwise sit dormant, these cross-references would almost never materialize. Pull is the proximate cause, even if GitHub's referencing mechanism is the underlying one.
It's also worth noting that GitHub now offers built-in automatic fork syncing, which covers the primary use case (keeping a default branch current via fast-forward). For the vast majority of casual forkers, the built-in feature is sufficient, which means Pull's user base is disproportionately generating upstream noise for functionality most of them no longer need. The niche cases Pull still serves (non-default branches, force-push on diverged forks) don't justify the impact on upstream maintainers who have no say in the matter.
The frustration from upstream maintainers is consistent across all of those issues: there is no way to opt out, no way to block
pull[bot], and no way to mute the timeline entries. Closing these reports as duplicates or "due to inactivity" doesn't make the problem go away. The README even has a "For Upstream Repository Owners" section that frames upstream owners as participants who should help configure Pull for their forks, yet offers them zero control over the noise it generates. If upstream owners are acknowledged stakeholders, they should have a voice.A few concrete suggestions:
#123,fixes #123), preventing GitHub from creating cross-references back to the upstream repo..github/pull.ymlconfig currently only serves fork owners. An option for upstream repos to signal "do not sync forks of this repo" would give affected maintainers recourse.xtqqczze commentedon Mar 19, 2026
This illustrates why issue links in commit messages are generally discouraged. For example,
rust-lang/rusthas a bot that warns:There are issue links (such as
#123) in the commit messages of the following commits.Please move them to the PR description, to avoid spamming the issues with references to the commit, and so this bot can automatically canonicalize them to avoid issues with subtree.
xmatthias commentedon Apr 2, 2026
While the app claims to "sync the fork" - clicking on "sync fork" in the github UI does not generate such a notification - so pulls will be doing something wrong, or at least significantly different to how github handles this internally.
Personally, i consider this as spam (not least because the author ignores the maintainer's issues) - and i've started reporting the pulls app for spam to the github safety team with screenshots of the spam.
i think if sufficient maintainers do the same, we can get github to take action against this behavior (ideally by changing the UI to not show this, or by removing the spam cause).