Git works well for large distributed teams. Very little software is developed like that. Most software is made by small teams. For small teams, git's model a

Git works well for large distributed teams. Very little software is developed like that. Most software is made by small teams. For small teams, git's model adds extra overhead. Small teams can be more productive with a simpler source repository. Release processes benefit from incremental commit numbers. They are easy to reason about in release planning. They are useful for gating features. Example: Wait until api server deploys commit number N or higher before enabling app feature A. They provide an easy way to track the age of binaries running in production. Example: We can turn down API B once every deployed production binary is built from commit number N or newer, since that is when we deleted the API B client library. Merging and rebasing is easier to understand with incremental commit numbers. Git has no support for code reviews. For example, it provides no functions for distributing versions of uncommitted changesets, distributing comments on uncommitted changesets, or linking comments to particular versions of changesets. These are core parts of the software development process. Code review comments are crucial context for future readers to understand the code. They belong in the repository with the code. Git's "stash" function is full of footguns and is therefore mostly unusable. Git's nomenclature is inexact. A git "commit" is actually a set of changes to files. It would be better called a "change set", "change list", or even "diff". Git's documentation needs work. It needs to explain common use cases. It needs to warn of more pitfalls. It needs more common use case examples. For example, https://git-scm.com/docs/git-revert https://git-scm.com/docs/git-revert has no example of specifying a particular commit or a set of commits. Another example, https://git-scm.com/docs/git-stash https://git-scm.com/docs/git-stash is missing a link to the article https://git-scm.com/book/en/v2/Git-Tools-Stashing-and-Cleaning https://git-scm.com/book/en/v2/Git-Tools-Stashing-and-Cleani... and that article needs a big fat warning about the biggest footgun: using 'stash' and then 'reset' and accidentally erasing untracked files that you thought were stashed. Git sees every source file as plain text, ignoring structure. For example, reformatting destroys blame info. Changeset metadata includes lines added/deleted/modified but treats whitespace changes the same as changes to comments, data, and logic. Git provides no access control functions. Users must rely on third-party tools. Users need to apply ACLs to source, code reviews, and test output. This is complicated to set up with third-party tools. I use git and I look forward to switching to a better tool in the future. Maybe Pijul will be it?