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."

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

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...