"Avery Pennarun" <apenwarr@xxxxxxxxx> writes: > Why do people (including me) spend so much time with a detached HEAD? > I think it happens mainly for the following reasons: > > 1) Checking out a remote branch "git checkout origin/master" detaches > my HEAD, which is kind of bad, since it's such a common thing to want > to do. I do not think it is bad at all. The feature to detach HEAD was designed for that kind of usage. Start sightseeing, possibly futz with the code, and even create some snapshot commits, and then: * if it starts to take a usable shape, say "git checkout -b my-topic", from there, to give your exploration a lasting home; or * if it doesn't pan out, just discard it with "git checkout -f master" (or whatever you wanted to switch back to). One thing that might help for downstream people would be to be able to say "I am making 'my-topic' branch out of a detached HEAD, but it really is meant to be a fork of origin/master that I detached my HEAD from, so please set up tracking for that one". You could force people to say "git checkout -b my-topic origin/master" from the beginning, but that is very unreasonable and unworkable. When you are exploring, you more often than not do not know where your quest would lead to until spending some time. It is quite important to be able to delay the decision to create a local branch to keep what you did, and (more importantly) to be able to delay deciding what to name that topic. Perhaps "git checkout -b my-topic" from a detached HEAD should inspect the HEAD reflog to see which remote (or local) branch you came from, and give that to the --track logic. > 2) git-rebase and git-am detach the HEAD while they work. I think > this is fine, but: you shouldn't be able to *reattach* the HEAD > without first aborting the rebase or am operations.... PS1='[\u@\h \W$(__git_ps1 " (%s)")]\$ ' would help here. I do not have an objection to the general idea of forbidding people from switching branches out of detached HEAD while sequencer is in effect as a safety measure, but I didn't think through possible negative implications. > The remaining situations where someone is working on a detached HEAD > (eg. checking out a particular commit, or actually implementing > git-rebase like operations) seem to be pretty obviously *intentional*, > and in that case, git should stay out of their way and let them do > what they're doing. Absolutely. Being able to explore, without having to first decide what you are going to work on or what to name that branch, is a wonderful feature. It really lowers the barrier to explore. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
