According to a recent message from Kees Cook, it was the "b4" tool that produced a mangled tree[1]. Try following the reflog: at that level, wrangling git is akin to juggling flaming live chainsaws.
Specifically the "b4 trailers" command, somehow. I don't have any special knowledge of b4, but it sounds as if a command that was expected to rewrite only the history of an under-review feature branch accidentally reached back too far and rewrote some of Kees' copy of master — without leaving a hint in the "Committer" field as it was conventionally supposed to.
Linus (rightly-ish) objected to this confusing breach of convention and did the contributor equivalent of a "revert quickly, debug at leisure." Kees (rightly) dug into the puzzle, figured out the problem, and explained it to Linus's (or at least Konstantin's) satisfaction.
This sort of thing is how I will never understand the attitude of people who claim that git is not actually confusing and you just have to learn it. If even the titans of kernel development (for whom git was created!) get screwed up, what hope do the rest of us have?
grumpymuppet · 1d ago
Right. There are two problems with software generally like this: interface and culture.
Becoming expert at a tool like git involves building familiarity with the concepts involved. While it's not entirely hidden in the --help and manual pages, the descriptions provided there do not consistently use higher levels semantic descriptions of the transformations. You are REQUIRED to look elsewhere to understand or worse -- develop a privately held theory of what's actually happening.
Culturally, a lot of engineers have a basic ethos of "getting things done". Getting the job of the moment done is a "win". There are tons of how do do XYZ articles that are separated from "why" and unmarried from useful additional context.
Like, one should be proud of learning a new tool, but it shouldn't be a personal endeavor to conquer Everest. I think it would do a LOT of good for tools -- especially collaboration tools -- to have completely standard introductions that the community enforced in collaboration. "Oh you don't know XYZ? You probably haven't read the standard introduction."
netfortius · 1d ago
> "You need to nuke that tree, and come up with a good explanation for this kind of shit."
...
> "Konstantin - please disable Kees' account immediately until this is cleared up"
Could Kees really nuke that tree, if Konstantin disables his account?!?
vdupras · 1d ago
If Linus is correct in his assumption that malicious work has to be involved to produce this tree (rather than being the result of merges and rebases gone wrong), it would indicate that Kees' development machines are compromised.
Maxious · 1d ago
Later in the thread it seems like https://github.com/mricon/b4 was involved. Maybe just a bug this time but exposes it as a weak link in the whole kernel contributor web of trust
chr1ss_code · 1d ago
I think this read deserves a more engaging title - for example 'WTF,Kees? - Kernel Maintainer Under Fire By Linus' :P
transpute · 1d ago
"Kernel Maintainer's git tree under fire by Linus, git creator"
[1] https://lore.kernel.org/all/202505312300.95D7D917@keescook/
Linus (rightly-ish) objected to this confusing breach of convention and did the contributor equivalent of a "revert quickly, debug at leisure." Kees (rightly) dug into the puzzle, figured out the problem, and explained it to Linus's (or at least Konstantin's) satisfaction.
https://b4.docs.kernel.org/en/latest/contributor/trailers.ht...
This sort of thing is how I will never understand the attitude of people who claim that git is not actually confusing and you just have to learn it. If even the titans of kernel development (for whom git was created!) get screwed up, what hope do the rest of us have?
Becoming expert at a tool like git involves building familiarity with the concepts involved. While it's not entirely hidden in the --help and manual pages, the descriptions provided there do not consistently use higher levels semantic descriptions of the transformations. You are REQUIRED to look elsewhere to understand or worse -- develop a privately held theory of what's actually happening.
Culturally, a lot of engineers have a basic ethos of "getting things done". Getting the job of the moment done is a "win". There are tons of how do do XYZ articles that are separated from "why" and unmarried from useful additional context.
Like, one should be proud of learning a new tool, but it shouldn't be a personal endeavor to conquer Everest. I think it would do a LOT of good for tools -- especially collaboration tools -- to have completely standard introductions that the community enforced in collaboration. "Oh you don't know XYZ? You probably haven't read the standard introduction."
Could Kees really nuke that tree, if Konstantin disables his account?!?