They are treated as the same thing at the UI level, hence your complaint. If they were treated as unrelated concepts then they would not both be serviced by gi

They are treated as the same thing at the UI level, hence your complaint. If they were treated as unrelated concepts then they would not both be serviced by git-checkout, despite sharing an underlying implementation. They are the same thing both in implementation and UI. The various consequences of detached commits and what happens when you try to modify the working tree when there are uncommitted changes are both concepts that permeate all of git. Handling these things in a graceful manner does not somehow mean that checking out branches or commits are fundamentally different concepts. If you want an example of muddled UI, git-checkout -b is an infinitely better example. Creating a branch is conceptually unrelated to checking out a branch; git-checkout just provides the -b flag for convenience because typically you want to check out the branch after creating it. It would likely make more sense to provide a --checkout flag of some sort with git-branch, as creating the branch is the primary operation and checking it out is just a secondary convenience. That is a decent complaint. If this is the sort of thing honestly that bothers you, then just make a git-changebranch alias for git-checkout, pretend that git-checkout can't do branches even though it can do arbitrary commits, and move on with your life.