WTF,Kees?(lore.kernel.org)
lore.kernel.org
WTF,Kees?
https://lore.kernel.org/all/CAHk-=wj4a_CvL6-=8gobwScstu-gJpX4XbX__hvcE=e9zaQ_9A@mail.gmail.com/
10 comments
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.
https://b4.docs.kernel.org/en/latest/contributor/trailers.ht...
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...
Should have followed the tried and true approach of https://xkcd.com/1597/
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?
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?
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."
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."
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.
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
> "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?!?
Could Kees really nuke that tree, if Konstantin disables his account?!?
[deleted]
I think this read deserves a more engaging title - for example 'WTF,Kees? - Kernel Maintainer Under Fire By Linus' :P
"Kernel Maintainer's git tree under fire by Linus, git creator"
[1] https://lore.kernel.org/all/202505312300.95D7D917@keescook/