3 ms·
This post is confusing a few things. Branches and tags are nothing more than prescribed semantics for certain refs by default. You could treat a tag as a branch
by xyzzy_plugh 4y ago
This post is confusing a few things. Branches and tags are nothing more than prescribed semantics for certain refs by default. You could treat a tag as a branch and vice versa if you really wanted. They're just refs. The tool has semantics around managing refs that map to branches and tags, but there's no hard rules here.
You're welcome to create your own configuration of refs and define how remotes handle refs. You don't need to use branches or tags, you can treat every ref as a tag if you like.
Branches and tags really are just refs. Any ref can be a branch or a tag. The refs don't behave in any way. They're just refs. The semantics are not frozen.
Take a look at git notes, or gerrit review refs, or GitHub pull request refs, or... any number of tools which build on the ref system.
git is surprisingly flexible, but ships with sane defaults. They're not gospel.
- jameshart 4y ago‘A branch is just a ref with some sane defaults’ is saying a strictly different thing than ‘a branch is just a ref’. Yes, you can do anything you can do to a branch tag to any other tag (or directly to any commit hash). Which means you can do things like ‘merge’ any of those things. Not just refs. So things that are not refs can act like branches. And you can’t just treat any ref as a branch. Is a remote a branch? No - so things that are refs can also not act like branches. X is Y can’t be true if there are instances of X that are not Y and instances of Y that are not X.
- chrisjc 4y agoThanks for taking the time to explain this. The idea that a lot of these names are just "prescribed semantics" really makes understanding git easier. I think it also drives home the point of how powerful, "simple" and thought out git is.