Linus Torvalds Just Called Out 330 Unexpected Commits During Kernel Merge

Last weekend, something unexpected disrupted the calm routine of Linux kernel development.

And it all started with a blunt message from Linus Torvalds:

“Kees, what’s going on here?”

Yes, that was from the Linux kernel mailing list.

But before diving into the details, let’s rewind a bit.

⚙️ Behind the Scenes: How Linux Kernel Code Gets Merged

The Linux kernel isn’t built by a small team in one office. It’s a global collaboration, with thousands of developers contributing patches and updates.

Each release begins with a merge window — a short period when maintainers submit their changes for the next version. This is when Linus Torvalds, as the final reviewer, decides what makes it into the kernel.

For Linux 6.16, things were going smoothly… until something unusual caught Linus’s attention.

🚩 Hundreds of Pull Requests — With Linus’s Name?

Linus noticed a batch of over 300 pull requests submitted by long-time contributor Kees Cook. That alone was a bit unusual.

But what truly raised concern was this: many of the commits looked like they had come from Linus himself.

Except they hadn’t.

“These aren’t my patches,” Linus said.

“Something’s seriously wrong here — and this kind of submission isn’t okay.”

At first glance, it appeared that someone — or something — had rewritten the history of commits in a very confusing way.

Linus paused all activity on Kees’s submissions and raised the issue for further review.

😬 A Misunderstanding — Or Something Deeper?

The issue wasn’t just about the number of pull requests. It was about who appeared to have authored them.

Some commits claimed to be from Linus. But their unique IDs — known as SHA-1 hashes — didn’t match any actual work he had done. For instance, one of Linus’s real patches had a hash of 9d230d500b0e, but the version in question had f8b59a0f90a2.

To Linus, this looked like an attempt to rewrite history in a way that wasn’t transparent. That’s a major red flag in any open-source workflow.

“This doesn’t look like a regular mistake,” he wrote.

“Until this is fully explained, I can’t accept anything else from this branch.”

🧊 Kees Replies: Something Went Wrong, But It Wasn’t Intentional

Kees responded quickly. He apologized for the confusion and said he was already investigating.

His first guess? A possible SSD issue. Maybe some file corruption had led to Git history being rewritten incorrectly. He said he’d rebuild the affected branches and double-check all future submissions.

But Linus wasn’t quite convinced.

“This seems far beyond a small slip-up,” he replied.

“When commit authorship and merge histories are altered on this scale, it signals a deeper problem — possibly in your tooling.”

That’s when the investigation got more technical.

🔍 The Real Cause: A Tool That Tried to Help

Soon, with help from Konstantin Ryabitsev, one of the Linux infrastructure maintainers, the team found the root cause.

It wasn’t a person making bad changes. It wasn’t a compromised environment. And it wasn’t a Git bug.

It was an automation tool called b4 — widely used in the Linux kernel workflow to simplify patch management and email-based reviews.

As it turns out, a script inside b4 was configured to use git-filter-repo, which — during a routine operation — ended up rewriting a large number of commits. In doing so, it changed author information and created what looked like misleading history.

So, in short: this was a tool misconfiguration, not a personal issue.

✅ Problem Solved — Accounts Restored, Lessons Learned

Once the issue became clear, Konstantin stepped in again.

“Linus, I’ve reviewed what happened. There was no intentional misuse here. It was a tooling error, and I’ve restored Kees’s access.”

Linus agreed — and requested one more thing:

“Let’s make sure b4 never touches commit author info again. That’s a line that should never be crossed.”

With that, things calmed down. The patch history was rebuilt. Access was restored. And the issue served as a reminder of how even helpful automation can sometimes go off-track.

💡 Why It Escalated So Fast

Some developers in the community felt Linus reacted too quickly. After all, it turned out to be an unintentional error.

But others pointed out: Linus’s job is to protect the integrity of the Linux kernel. If something looks off — especially in the critical areas like commit history — it’s his responsibility to sound the alarm.

In open-source, trust and traceability are everything. If the history of who changed what becomes unreliable, the whole system suffers.

🧠 What This Teaches Us

1. Automation can do strange thingsTools like b4 are helpful — until they aren’t. Scripts need guardrails.
2. Commit metadata mattersAuthor and history info is critical for trust. It’s more than just names — it’s about responsibility.
3. Quick reactions can prevent real damageIt’s better to halt and verify than to accidentally merge flawed or confusing history.

🐧 Final Thoughts

What started as a surprising email turned into a deep dive into Git tools, developer trust, and the invisible complexity behind the world’s most important open-source project.

No harm was done. No data was lost. But the situation was a reminder: even in highly engineered workflows, unexpected things can happen.

And when they do — it’s how the community responds that really counts.