Git Contributors Draft a Debian-Style Vote on Whether to Keep the Ban on AI-Looking Patches

Git's contributors are drafting a formal vote on the project's policy toward AI-generated patches, and as of the latest reporting they have not agreed on who gets a ballot. The draft process was posted on October 21, 2026 by Emily Shaffer, according to LWN's account of the discussion.

The policy being contested is already in the tree. It sits in the SubmittingPatches document, and it is blunt.

What the current policy says

The document says: "we will reject anything that looks AI generated, that sounds overly formal or bloated, that looks like AI slop, that looks good on the surface but makes no sense, or that senders don't understand or cannot explain."

Its legal argument rests on the Developer's Certificate of Origin, the Signed-off-by: trailer every contributor adds. The page says it is "not yet clear that this can be legally satisfied when submitting significant amount of content that has been generated by AI tools."

LWN reports the policy dates from October 2025. It was raised again at the 2026 Git Contributor's Summit, where participants reached no conclusion. Some were open to relaxing it. Others cited copyright and a loss of trust in the project.

The one thing the room agreed on was that it could not reach agreement, so someone suggested a vote.

How the vote would work

Shaffer's draft borrows from Debian's process but differs from it, LWN says. The maintainer decides when a vote happens. Proposals arrive as patches to project documentation, and one reaches the ballot only if a second eligible voter seconds it.

The schedule is about four weeks of discussion followed by a two-week voting period.

Open question	What the draft says
Who can vote	A merged commit in next, or two or more code reviews, and not banned
Vote counting	Not specified
Discussion period	About 4 weeks
Voting period	2 weeks

The eligibility rule is where the thread is argumentative. The Summit floated a threshold of 50 commits and dropped it. Patrick Steinhardt suggested 25 or 30. Jeff King proposed a rule that weights long-term contributors more heavily. brian m. carlson asked for a threshold that does not push people to contribute only in order to vote.

None of these won. The vote-counting question is just as open: LWN names Debian's devotee tool and the Condorcet Internet Voting Service, which the Linux Foundation uses for Technical Advisory Board elections, as candidates.

The objection to voting at all

Kristoffer Haugsbakk predicted the outcome in advance. Developers employed by companies would, he argued, drift toward their employers' positions, and he wrote: "The vote will pass."

Steinhardt and carlson replied that they would vote on their own conclusions. Both said the ballot should be secret so employers cannot lean on developers.

LWN also notes that adopting a voting process is itself a governance decision that may need the consensus the project could not find on the AI question.

What is still unknown

The draft does not list the options on the ballot. LWN's article describes the existing policy and the general possibility of relaxing it, not a text anyone has put forward as an alternative.

LWN's article does not report a date for a vote. Under the draft the maintainer chooses it. Coding agents are also straining Git from the hosting side, as OpenAI's acquisition of Pierre Computer showed on November 4. On the tooling side, agent-browser 0.42 is another agent project shipping this week.

The next concrete step is a settled eligibility rule. Until then, the rule stays as written: a patch that looks like AI slop gets rejected.