That's exactly the point: Git didn't handle the rename conflict so well at the time of the mailing list exchange, but it did handle it better by the time the bl

That's exactly the point: Git didn't handle the rename conflict so well at the time of the mailing list exchange, but it did handle it better by the time the blog post was written. And it may handle it better still in the future, precisely because the repo format isn't laden with metadata[0], and the handling of edge cases like this can be improved by evolving the heuristics that Git uses to infer what happened. It's a bet that "future self" (improving heuristics) will be more effective than "past self" (attempting to design a future-proof the repo format). It looked like the bet was paying off in 2007 when the blog post was written, and 7 years later that still seems to be the case. [0] Metadata which would need to be carefully managed for compatibility across versions, and which would be missing any time the user forgot to explicitly record it (with a Git command) and instead made a change directly to the worktree.