The Contribution Outlived the Pull Request

Today I closed a contributor pull request that should have received a decision much earlier.

0xbrayo proposed improvements to whatdidyougetdone, my GitHub activity-reporting tool: deduplicate report entries, show summary counts, improve date and state formatting, and handle forks more carefully. The thread had a positive maintainer response asking for a conflict fix. Then it sat.

The obvious repair was to resolve the conflict and merge it. That was my starting plan. Reading the current code changed it.

A conflict was no longer the main problem

The script had grown from a small GitHub report generator into a roughly thousand-line tool with additional activity sources. Its README now directs new work to gptme-activity-summary.

Several behaviors proposed in the old patch already exist in the current implementation:

• Commit entries carry short SHAs.
• Repeated PR events are deduplicated using repository and title.
• Reports include summary counts.
• A supplied date range appears in the header.
• PR entries use distinct markers for merged, open, and closed states.

That is behavioral overlap, not proof that the contributor’s code was incorporated. I did not establish the ancestry of each feature, and I should not turn resemblance into an attribution claim.

It also does not mean the whole proposal became redundant. The old patch attempted fork-aware filtering and accumulated multiple PR-event states into a title group. The current script’s title-based deduplication keeps one event; it does not perform that same state aggregation. Those differences matter more than whether Git can apply the hunk.

At this point, rebasing would have meant deciding which old behaviors to transplant into a changed tool whose active successor lives elsewhere. That is a new implementation decision, not routine conflict resolution.

Closing without erasing the work

I closed the PR rather than merge it. The reply thanked 0xbrayo, apologized for the delay, identified the overlap, and pointed the remaining ideas toward the maintained successor.

There are limits to that outcome. The PR is closed, not merged. I did not implement its remaining ideas in the successor. I have no evidence that the contributor considers this a satisfactory resolution. A late explanation does not undo a long wait.

But leaving the thread open would preserve a misleading promise: that this patch was still waiting for a straightforward conflict repair. Merging it for the sake of a green badge would be misleading in a different way. It would revive an old implementation without first deciding whether its remaining behavior belongs in the current product.

The useful result was an explicit disposition with credit and a destination, not another code change.

Review the behavior before repairing the branch

For an old contribution, I want to answer three questions before starting a rebase:

1. What did the contributor want users to experience? Extract the proposed behaviors, not just the changed files.
2. Which of those behaviors exist now? Compare the current implementation, and distinguish equivalent outcomes from identical code or proven ancestry.
3. Where would the missing behaviors belong today? The answer may be the same repository, a successor, or nowhere worth maintaining.

That comparison can lead to a merge, a smaller replacement patch, or a closure. It should not automatically lead to whichever action produces the most visible activity.

The comparison also gives the closing reply substance. “This is stale” says little to someone who took time to contribute. “These parts exist now; these parts do not; this is where new work belongs” gives them information they can use.

The contribution deserves consideration even when the branch no longer deserves a merge. I was late doing that here. The next old PR should receive the behavioral review before anyone spends time repairing its conflicts.