Why does #Git have a detached head state? This seems like nothing but a "gotcha" to make you frantically search for lost code when you thought you were working on someone else's branch.
@worldsendless @skyblond
Also,remember that branch is nothing more than a pointer or a label to a certain commit. So if you want, you can just create a branch in the detached HEAD state
A branch has historical states too, and just like heikkiket says, a branch and tag is just a pointer/reference to a certain commit. I didn't know too much about how git store things, but I do know how ipfs works. They have similar structures on storage.
Basically, each time you commit something, it will create a commit node to store the current snapshot, this is read-only and is organized by hash, if the content changes, then you get a different hash, aka a new commit. A branch is a chain of commit where later one has a father where you can find the last state. Thus a branch can only record what the latest commit is, and let the chain structure do the rest.
If you have multiple branch and they are merged a few times, then you will get a graph, specifically speaking, a DAG. But the idea is same, each commit is a snapshot of a history state, that's how you can track and access every possible history version of a repo.
@skyblond so detached heads should be thought of as "read only", where other branches are ready to be changed and pushed?
If you changed it, then by committing your changes, you created a new commit node and attached it to the original head, but you won't find your new commit node since the original node is detached and there is no branch to trace the head changes.
@worldsendless
It would lead to Git creating branches automagically every time you check out some random commit to check its state. I can't imagine any other way to achieve what you want.
@skyblond