Git Project May Vote on LLM Contribution Policy: What Developers Should Know

The Git project — the toolchain behind most of the world's repositories — may adopt a formal vote to decide whether large language model output belongs in official patches, according to Jonathan Corbet's November 9, 2026 LWN report. Until that vote lands, Git's own documentation still tells contributors maintainers will reject patches that look AI-generated or that authors cannot explain.

If you ship coding agents, this is upstream policy catching up to Copilot, Claude Code, and Codex volume. If you maintain open source, it is the mirror of GPL and LLM laundering questions we tracked earlier in 2026.

TL;DR

Background: the October 2025 SubmittingPatches warning

Git maintainers may vote on whether LLM-generated patches belong in git.git

Git's SubmittingPatches documentation is the law of the land for git.git. LWN notes Git added language in October 2025 tying the Developer's Certificate of Origin (DCO) to a blunt AI rule:

• Contributors must certify they know the origin of their work.
• Legal uncertainty remains whether that certification holds for large AI-generated chunks.
• Maintainers will reject patches that look AI-generated, read like bloated formal prose, or that authors cannot explain.

That is stricter than "disclose Copilot use." It is presumptive rejection when maintainers smell slop.

The text matters because Git is not a hobby repo. Kernel vendors, package maintainers, and CI vendors treat its governance as a precedent. Our fragile-codebase agentic coding discussion showed practitioners already nervous about unexplained agent diffs landing in production trees.

What happened at the Contributors Summit

Corbet's article walks through 2026 summit debate:

• Some maintainers want relaxation — treat LLMs like advanced editors if humans understand the result.
• Others cite copyright ambiguity and trust erosion if bots flood the list.
• Consensus only went as far as "we will not reach consensus."

Hence the vote proposal — unusual because Git is not a democracy. The maintainer still merges. A ballot is a pressure valve when social consensus fails.

Emily Shaffer's draft voting process (October 21)

Key mechanics LWN summarized:

Open holes remain: vote counting method (Condorcet versus simple majority), and eligibility thresholds. Summit hallway talk mentioned 25–50 commits as a bar; the draft is more inclusive.

Kristoffer Haugsbakk argued the outcome is foreordained — monthly contributors work for vendors who want AI acceptance. Patrick Steinhardt and brian m. carlson pushed back, but agreed secrecy matters.

What developers are saying

The LWN thread itself is the best HN-style signal (the HN submission had no comment thread yet on November 10).

Debian comparison. Subscriber bayindirh praised Debian's "regardless of tool, the user is responsible" framing while disliking "LLMs for everything."

Status-quo drift. aragilar warned Debian's compromise positions erode over successive votes — relevant if Git copies Debian mechanics without Debian's decades of process muscle.

Hand-tool philosophy. Wol argued AIs are tools like early chainsaws: dangerous until operators learn them — but maintainers must still reject work authors do not understand.

Hallucination versus bad code. smoogen joked that bad code "works wrong," while hallucinated review comments invent CVEs in malloc and love letters to Ada — a reminder that LLM review bots can be worse than LLM authors.

None of these comments bind Git policy, but they show practitioner fault lines: copyright, employer pressure, and explainability.

How this differs from the Linux kernel LLM fights

Git is the VC layer; the kernel is a consumer. Kernel maintainers already tightened subtrees. Git setting policy at git.git affects:

• Git for Windows maintainers
• libgit2 and JGit downstream packagers
• Corporate mirrors that copy contribution rules into CLA/DCO handbooks

If Git votes to ban unexplained AI patches, expect GitHub Enterprise admins to paste the same language into internal contribution guides — even if GitHub the company disagrees.

Cross-read our loop engineering for coding agents guide: loops fail when agents cannot justify diffs to a human reviewer.

Practical guidance for agent teams (November 2026)

Until a vote passes:

1. Never open a git.git PR from an agent without a human who can explain every hunk live on the list.
2. Keep audit logs — prompts, model version, and reviewer sign-off — for your own repos; Git's rule is the extreme case of what's coming elsewhere.
3. Prefer small patches — Git culture already punishes sweeping rewrites; agents make that worse.
4. Run git diff --check and project pre-commit hooks before mailing lists see your work — Git's docs explicitly call this out.

For security-sensitive projects, pair process with agent insider governance ideas.

What to watch

• Maintainer announcement that voting opened (watch git@vger.kernel.org if you subscribe).
• Whether proposals ban, disclose, or Debian-style responsibility models win.
• Downstream copies in GitLab, Bitbucket, and GNOME foundations.

Debian, Linux, and kernel lessons Git voters cite

Open-source governance votes shape whether AI-written code can ship in Git itself

LWN commenters keep returning to Debian's social contract because Debian already survived a systemd vote and periodic DFSG interpretation fights. Git's proposal is smaller in scope — one documentation policy — but the process shape rhymes:

Kernel maintainers, meanwhile, never held a global LLM vote; subsystems simply tightened maintainer discretion. Git setting a written rule at the VC tool layer is closer to tying your shoes before the kernel walk — everyone uses Git even if they ignore kernel politics.

Corporate CLA teams are watching

If Git votes "explain every hunk or we reject it," expect:

• OpenRewrite and agent vendors to add mandatory human attestation fields in PR templates.
• Legal to update employment agreements — "you certify understanding" becomes HR training.
• Insurance riders on open-source contributions for companies shipping agent products.

Our Janestreet Socratic tutor skills post showed serious shops already encode pedagogy before autonomy. Git's rule is the stern uncle version.

What a ranked-choice outcome could look like

Because the draft does not pick a counting method, participants floated:

• Condorcet Internet Voting Service (used in Linux Foundation TAB elections per LWN).
• Debian's devotee tooling.
• Plain approve/reject each proposal patch.

If multiple proposals land on the ballot — full ban, disclose-only, Debian-style responsibility — ranked choice avoids spoiler outcomes where a strict ban splits votes with a moderate compromise. Git has never needed this machinery before; maintenance overhead is real.

Agent vendor checklist (pre-git.git contribution)

1. Human author of record on every emailed patch series.
2. Attestation template in cover letter: tools used, models, prompts summarized.
3. Reject auto-generated commit messages that read like release notes.
4. Run project's own tests — Git docs already demand this; agents often skip.
5. Never send volume flips — SubmittingPatches culture rewards surgical series.

Claude Code users should read our hidden IP reminder injection post before assuming local agents are safe to pipe directly to git send-email.

Why this matters for Windows and macOS developers

Git for Windows and GitHub Desktop consumers far outnumber git.git contributors. But policy tone travels: Microsoft’s GVFS teams and GitHub Copilot product managers cite upstream norms when drafting org-wide AI contribution bans.

If you maintain a mirror of Git's docs in your company handbook, schedule a review the day Git posts vote results.

Historical note: why Git avoids votes until now

Git grew from a mailing-list culture where the maintainer decides after reading threaded review. Voting is a delegation of legitimacy, not speed. Emily Shaffer's draft exists because LLM contributions break the old assumption that every contributor typed the diff. Agents violate that assumption at scale.

When the vote eventually closes, watch whether Git codifies rejection (status quo), codifies disclosure, or imports Debian's responsibility principle. Each outcome propagates to GitHub Copilot terms, GitLab Duo policies, and internal harnesses within quarters, not years.

Bottom line

Git may democratize a question most companies still dodge: who is legally and technically responsible for LLM output in shared infrastructure code? Today's documentation answers harshly — if you cannot explain it, maintainers reject it. The vote might soften that, tighten it, or deadlock forever.

Agents are welcome in your private monorepo. For git.git, bring a human who can defend every line on a mailing list.

Related reading

• Asahi Linux GPL and LLM code laundering debate
• Fragile codebases under agentic coding
• Loop engineering with coding agents
• Claude Code commands reference
• Addy Osmani's production agent skills pack
• Design.md templates for agent UI work
• What are agent skills
• Microsoft insider agent governance

Policy quotes summarize LWN's November 9, 2026 article and Git's public SubmittingPatches documentation; the vote is draft until the maintainer calls a ballot.