> A branch is a DAG of commits terminating at one commit. [Pedantically] this includes orphaned branches. > They should have just called it a pointer if it's

> A branch is a DAG of commits terminating at one commit. [Pedantically] this includes orphaned branches. > They should have just called it a pointer if it's a pointer. A branch in every VCS is first and foremost a name. That name has to evaluate to a) content, b) history. In Git and Git-like immutable-commit systems this can trivially be implemented by a table mapping branch (and tag and...) names to commits. I.e., in any immutable-commit VCS branches are naturally pointers. The only real question is whether there should be additional semantics layered upon the pointer nature of branches. Indeed, there should be. In Git these are the basic rules: - branch names are updated when adding commits in a workspace that has that branch checked out - tag names are NOT updated when adding commits when adding commits in a workspace that has that tag checked out - local configuration can enforce a variety of rules via commit hooks - upstreams can enforce a variety of rules, such as fast-forward-only (no history rewriting) This gives users a great deal of flexibility, including the ability to ban history rewriting on published branches and to allow it on unpublished branches.