News for hackers. Stuff that matters.
Re:Flight rules for Git by xyzzy_plugh on Tuesday October 16, 2018 @11:54AM (#18230359)
Detached HEAD isn't complicated. It simply means there is nothing tracking the current line of work beyond the commit shas themselves. No branch is updated when you make commits.

Conversely, attached HEAD means a branch is being updated whenever you make a commit, e.g. when you make commits on your local master.

Re:Flight rules for Git by lixtra on Tuesday October 16, 2018 @12:27PM (#18230678)
Oh, I see. I created this great patch and commited it. Then I wanted to push it, but it reported some strange error.

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.

Re:Flight rules for Git by seba_dos1 on Tuesday October 16, 2018 @12:40PM (#18230806)
All I get from this comment is that "git reflog" should be one of the first things taught about git :P
Re:Flight rules for Git by lixtra on Tuesday October 16, 2018 @12:54PM (#18230943)
Maybe reflog would help. Unfortunately most cheat sheets I saw don't mention it.
Re:Flight rules for Git by craftyguy on Tuesday October 16, 2018 @02:01PM (#18231592)
As other comments here have suggested, git cheatsheets should be ignored if you are learning git.
Re:Flight rules for Git by iainmerrick on Tuesday October 16, 2018 @12:20PM (#18230616)
But why would I get into that state, and how do I get out without losing my work? Neither of those is obvious.
Re:Flight rules for Git by tome on Tuesday October 16, 2018 @12:22PM (#18230633)
> how do I get out without losing my work?

When you move out of detached head state by checking out another branch Git tells you how to save your work to a branch.

Re:Flight rules for Git by iainmerrick on Tuesday October 16, 2018 @12:49PM (#18230905)
It could usefully say that when you do a “git status” when you’re in a detached state, instead of just saying “detached HEAD” and expecting you to figure it out (or google for it).

It could very usefully try harder to avoid getting into that state in the first place.

Re:Flight rules for Git by annabellish on Tuesday October 16, 2018 @12:58PM (#18230993)
>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?

Re:Flight rules for Git by jamescostian on Tuesday October 16, 2018 @01:24PM (#18231248)
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

Re:Flight rules for Git by mappu on Tuesday October 16, 2018 @05:08PM (#18233282)
> 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.

Re:Flight rules for Git by WorldMaker on Tuesday October 16, 2018 @02:37PM (#18231967)
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..."

Re:Flight rules for Git by Latty on Tuesday October 16, 2018 @07:22PM (#18234161)
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.
Re:Flight rules for Git by tome on Tuesday October 16, 2018 @12:52PM (#18230928)
> It could usefully say that when you do a “git status” when you’re in a detached state

That's a great idea and it really confuses me why they don't add obviously useful things to the interface.