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.
I guess it just allow you to access a historical status/state. Just like you can review every possible "snapshot" of the repo, that's the thing support the version control behind the scenes.
@skyblond but why not just make it an ordinary branch? Why headless?
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.
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.
@skyblond so detached heads should be thought of as "read only", where other branches are ready to be changed and pushed?