This blog entry is a gentle and accurate rant/observation on git usability: it's still not working, so why do we put up with it? I would recommend the comment

This blog entry is a gentle and accurate rant/observation on git usability: it's still not working, so why do we put up with it? I would recommend the comment by edblarnes: > Git is a brilliant data model that we hack into being a code repo. > It was designed from the model backwards, not the use cases inwards Git can do a million things no one uses it for. It practice, teams develop and teach a happy-path workflow, and then for other things they drag in the git expert. But users do random walks through git operations, wasting everyone's time. Design-wise, it's 80/20 again: most teams mostly work with gitflow-style workflows, with various rules -- AND most have some tiny variations they work in, so there's minimal capture of workflow. As an aside, my gripe with git is text diffs and commit histories. It's simply too hard to understand changes and to review code when you have no control over the granularity of the change and are forced into per-commit granularity of comments (and even those are lost in squash). At the very same time that we want to increase code velocity, teams have to impose e.g., 500-line limits on diffs to keep code reviews manageable. This slows change to tiny incremental steps. But they're only undigestible because the actual change is lost in the details, and commit comments have to decide between high-level changeset overviews or low-level file change descriptions. We need to zoom in and out to different levels of comments and changes. IBM's 1990's (closed-source) Visual Age saved code as an AST, and could do great diffs. But now with LLVM and LSP, we're much, much better at sharing underlying infrastructure of languages. My minimal rule for next-git would be that any automatable refactoring should appear as the one tiny change it is (renames, extracting methods, hoisting members in the hierarchy, etc.) in any language. The reason we don't is not technical, because logical diffs are achievable. It's the coordination costs of shifting everyone from git to something else. Given that, one option now is to support text conventions for commit comments that bridge comment levels and incorporate AST-level descriptors. They might be readable by humans, but most humans would use tooling to fly over and dive in. The path to designing that is to work out the main and troubling use-cases, propose some formats, build in evolution/compatibility, and make some prototypes. If people want to make a name for themselves, this is a way to do it that could transform the industry. If a company wanted to make code understandable to AI, this is the transformative way to do it. If you squint, metadata over change is a model of intelligence. There's a lot of headroom in the space of building systems to feed AI instead of feeding human garbage into AI at sufficient volume to compensate for noise.