Comment by Buttons840 | Hacker News Reader

Comment by Buttons840 | Hacker News Reader

Parent Full thread

> WTF is "detached HEAD"? I've looked it up dozens of times, and as soon as I get past whatever I'm working on, I forget what it means. I don't know what the reflog is, other than that it has to do with some dark internals.

I could answer, but I don't think you're actually asking for someone to explain it to you.

I did want to offer a different opinion though. I like detached heads, they are unnamed branches, the first thing I do when working on something new is make a detached head and get to work, making commits, etc, if I decide the work is worth keeping, then I will name the branch. As some smart people have said, naming things is hard, I don't want to name a branch before I'm sure what it is or that I'm going to keep it. Having a bunch of commits that are not part of a branch might sound risky, but not if you understand that commits are never deleted (unless there 90 days old or more) and the reflog and other tools allow you to find commits you thought might be lost. Git does not lose commits, not ever.

Naming is only hard if the names are permanent (cough fossil & hg)

But git names are not permanent, so just use whatever helps you remember: "just-ate-tuna-sandwich", "fifth-time-is-a-charm", "john-is-late", "idea-from-restroom", even "temp123"...

You can always rename to something that makes sense later.

Yup, my names break up into two categories, each with a namespace: `wip/` and `deadend/`. deadend is my personal favorite. Every time I write some code that turns out to not work, instead of spamming undo until I get to a known good state, I do:

    git commit -am “Dead-end: I tried doing X but that didn’t work out”
    git branch deadend/tried-doing-x
    git reset —-hard HEAD^

I like this because, fully half the time I end up needing to draw some elements from that dead-end if it turns out later to have seeds of the right approach in it.

`git branch <something-temporary>` is an absolutely fantastic workflow IMO, combined with committing early-and-often, it helps me decide on logical names for various snapshots of where I was when trying to solve a problem. When I hear people say “squashing is wrong” I can never understand what they’re on about: being able to make temporary semi-meaningful commits and branches on your way to the right answer to a problem, is an absolute godsend.

Yeah, not really looking for an answer. I have a decent idea, and I could guess. It's one of those things where when I find myself in that state, it means I messed something up. I google, read a few sentences, remember what it means and how to get to the state I want to be, and then move on with my life without committing the details to memory. It's one example of the confusing scenarios I find myself in with Git with more frequency than seems necessary. I'd rather debug a Kubernetes cluster.

Git does make a detached head sound like something is broken, but it's really just a nameless branch. Nothing broken about it. Any commits might become hidden, as all commits not in a branch are, but that's only after you move off the headless branch and git warns loudly about this.

I just tested to see what happens if you don't name a branch before leaving it. Surprisingly, despite all that scary looking text about detached head, if you switch over to another branch git will print out a message that you're leaving commits on an unnamed branch as well as instructions on how to get back and name it later (and of course the commit hash can also be recovered from the reflog).

So yeah not only is the detached head state not a broken state, it's not even really a scary state to be in.

For someone who understands git, it certainly is not. But if you are not aware of how git works, committing things when HEAD is detached could to confusion in the best case, and lost commits in the worst.

Naming is trivial, _1, _2 , etc, exist.

Good naming is hard, but you don't need those for your use case of potentially discardable work

I just use stacked branches and work out of the top branch. When changes are solid -ish I move down a level in the stack and cherry pick isolated changes into small/focused commits. Then I put the entire stack in review with a doubly linked list references so the reviwer can walk up and down the stack to see the corpus of changes.

That way a 1000 line pr consisting of 25 commits can be landed as 5 dependant prs with a much more focused review.

Reply on news.ycombinator.com