Conversely, attached HEAD means a branch is being updated whenever you make a commit, e.g. when you make commits on your local master.
I checked out master but now my commit is no longer there. HELP!
Can I somehow push my changes to you so you can fix it?
Ah let's intuitively try:
git log --graph --decorate $(git rev-list -g --all)
For comparisson:
- mercurial would show your commit all the time, no matter what currently is checked out.
- Only when you push, you have to force it, to create a new head in the remote repository because most workflows expect you to merge heads locally.
When you move out of detached head state by checking out another branch Git tells you how to save your work to a branch.
It could very usefully try harder to avoid getting into that state in the first place.
Am I missing something here? How do you get into a detached HEAD state without explicitly taking an obviously weird action, like finding and checkout out a commit hash instead of a branch, and why would it make sense for git to not be in a detached HEAD state should you do that?
Most people don't think about doing a hard reset to the last good commit, and then soft resetting to HEAD~. Instead, they just "git checkout $LAST_GOOD_COMMIT". And afterwards they may even continue by working with a detached HEAD
But this isn't an obviously weird action? It happens all the time when you need to branch off from a previous point.
Maybe you're unexpectedly releasing a hotfix, maybe your current development is going in a bad direction, maybe you need to test something against a previous state.
Several times that I've helped junior developer out of a detached HEAD state, when I asked what they thought they were doing before it happened, the answer was "I was just doing my normal rebase before..."
That's a great idea and it really confuses me why they don't add obviously useful things to the interface.