{"thread":{"id":"50170","subject":"Recovering from a \"detached from\" HEAD","startedAt":"2019-01-07T16:17:55Z","lastAt":"2019-01-08T14:44:26Z","messageCount":4,"participants":["Alyssa Ross","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"366260","messageId":"20190107161748.pyhgpewymdgjmgoh@x220","threadId":"50170","inReplyTo":null,"subject":"Recovering from a \"detached from\" HEAD","fromName":"Alyssa Ross","fromEmail":"hi@alyssa.is","sentAt":"2019-01-07T16:17:48Z","receivedAt":"2019-01-07T16:17:55Z","isPatch":false,"sender":{"key":"hi@alyssa.is","avatar":"https://avatars.githubusercontent.com/u/2768870?v=4"},"body":"If I detach my head, then use `git subtree add` to generate a commit,\nthe output from `git status` changes from \"detached at SHA\" to\n\"detached from SHA\". The sha doesn't change, but HEAD has updated.\n\nI don't understand why `git status` doesn't tell me that I'm\n\"detached at\" the sha of the new commit, but not only that, it seems to\nbe extremely difficult to get `git status` to reflect my actual HEAD.\n`git checkout HEAD` doesn't change it, `git checkout NEWSHA` doesn't\nwork.\n\nSo my question is, what's going on here? Is this intentional behaviour,\nor a bug? How should I get my working tree back to a normal state?\n"},{"id":"366282","messageId":"xmqq8szw8d8o.fsf@gitster-ct.c.googlers.com","threadId":"50170","inReplyTo":"20190107161748.pyhgpewymdgjmgoh@x220","subject":"Re: Recovering from a \"detached from\" HEAD","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-01-07T19:43:51Z","receivedAt":"2019-01-07T19:43:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alyssa Ross writes:\n\n> If I detach my head, then use `git subtree add` to generate a commit,\n> the output from `git status` changes from \"detached at SHA\" to\n> \"detached from SHA\". The sha doesn't change, but HEAD has updated.\n\nThis is expected, and there is nothing to \"recover from\". Use of\n\"git subtree add\" should be irrelevant (iow, you should get the same\nbehaviour no matter _how_ you build new commits on the unnamed\nbranch).\n\n $ git checkout --detach\n $ git status -uno\n HEAD detached at 9745ede235\n $ git commit --allow-empty -m empty\n [detached HEAD bc9a31f2df] empty\n $ git status -uno\n HEAD detached from 9745ede235\n\nThe commit the message shows is meant to indicate where your unnamed\nbranch diverged at named branches. Immediately after moving to the\nunnamed branch by detaching the HEAD, the message says \"at\"; the\nHEAD is pointing directly at the tip of the then-current branch and\nthat is where the tip of the unnamed branch is. You can tell from\nthat message that you will not lose any commit if you were to check\nout a named branch from that state.\n\nAfter you make a commit on the unnamed branch, you have something to\nlose if you were to check out a named branch from that state, as the\ndetached HEAD is the _only_ thing these new commits you built on top\nof the fork point. Upon seeing \"HEAD detached from 9745ede235\", you\ncould do \"git log 9745ede235..\" and see what you would end up losing\nif you were to switch to another branch without saving them first to\na named branch.\n\n> So my question is, what's going on here? Is this intentional behaviour,\n> or a bug? How should I get my working tree back to a normal state?\n\nThere is nothing abnormal in this state while you are working on an\nunnamed branch.\n"},{"id":"366329","messageId":"20190108141927.a4q5fqug3ymkh5v3@x220","threadId":"50170","inReplyTo":"xmqq8szw8d8o.fsf@gitster-ct.c.googlers.com","subject":"Re: Recovering from a \"detached from\" HEAD","fromName":"Alyssa Ross","fromEmail":"hi@alyssa.is","sentAt":"2019-01-08T14:19:27Z","receivedAt":"2019-01-08T14:19:33Z","isPatch":false,"sender":{"key":"hi@alyssa.is","avatar":"https://avatars.githubusercontent.com/u/2768870?v=4"},"body":"> The commit the message shows is meant to indicate where your unnamed\n> branch diverged at named branches. Immediately after moving to the\n> unnamed branch by detaching the HEAD, the message says \"at\"; the\n> HEAD is pointing directly at the tip of the then-current branch and\n> that is where the tip of the unnamed branch is. You can tell from\n> that message that you will not lose any commit if you were to check\n> out a named branch from that state.\n>\n> After you make a commit on the unnamed branch, you have something to\n> lose if you were to check out a named branch from that state, as the\n> detached HEAD is the _only_ thing these new commits you built on top\n> of the fork point. Upon seeing \"HEAD detached from 9745ede235\", you\n> could do \"git log 9745ede235..\" and see what you would end up losing\n> if you were to switch to another branch without saving them first to\n> a named branch.\n\nThank you for the detailed explanation. I was for some reason under the\nimpression that \"git status\" would show the current HEAD, rather than\nwhere it was detached. Why I thought that, I don't know.\n"},{"id":"366330","messageId":"xmqq36q36wfw.fsf@gitster-ct.c.googlers.com","threadId":"50170","inReplyTo":"20190108141927.a4q5fqug3ymkh5v3@x220","subject":"Re: Recovering from a \"detached from\" HEAD","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-01-08T14:44:19Z","receivedAt":"2019-01-08T14:44:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alyssa Ross writes:\n\n>> The commit the message shows is meant to indicate where your unnamed\n>> branch diverged at named branches. Immediately after moving to the\n>> unnamed branch by detaching the HEAD, the message says \"at\"; the\n>> HEAD is pointing directly at the tip of the then-current branch and\n>> that is where the tip of the unnamed branch is. You can tell from\n>> that message that you will not lose any commit if you were to check\n>> out a named branch from that state.\n>>\n>> After you make a commit on the unnamed branch, you have something to\n>> lose if you were to check out a named branch from that state, as the\n>> detached HEAD is the _only_ thing these new commits you built on top\n>> of the fork point. Upon seeing \"HEAD detached from 9745ede235\", you\n>> could do \"git log 9745ede235..\" and see what you would end up losing\n>> if you were to switch to another branch without saving them first to\n>> a named branch.\n>\n> Thank you for the detailed explanation. I was for some reason under the\n> impression that \"git status\" would show the current HEAD, rather than\n> where it was detached. Why I thought that, I don't know.\n\nI wrote not from the documentation but from what I remember about\nthe discussion that led to final phrasing of the message, and I\nstrongly suspect that your impression is the sign that our docs are\ninsufficient. If you can spot where we can improve on, that would\nbe great.\n\nThanks.\n"}]}