[annabellish]

>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?

[jamescostian]

Imagine someone does task X but they do it very poorly and in master. You want to get rid of their last few commits (without a force push).

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

[mappu]

> an obviously weird action, like finding and checkout out a commit hash instead of a branch

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.

[WorldMaker]

Rebase has several cases that will drop you into a detached HEAD. Rebase has gotten better at warning you when it is happening, and much better at telling you what your next steps are in that situation (such as git rebase abort), at least, but it still does it.

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..."

[Latty]

It is (or at least used to be) pretty easy to end up with a detached HEAD when working with submodules and aren't sure what you are doing. It definitely didn't need an "obviously weird" action.