{"thread":{"id":"25899","subject":"Proper way to checkout a tag?","startedAt":"2010-12-01T19:38:00Z","lastAt":"2010-12-02T08:33:18Z","messageCount":4,"participants":["Dun Peal","Jonathan Nieder","Michael J Gruber"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"156991","messageId":"AANLkTi=b12n0J+Qg4S7i9dnbMHoWvPS3OXP0CDZevT_4@mail.gmail.com","threadId":"25899","inReplyTo":null,"subject":"Proper way to checkout a tag?","fromName":"Dun Peal","fromEmail":"dunpealer@gmail.com","sentAt":"2010-12-01T19:38:00Z","receivedAt":"2010-12-01T19:38:00Z","isPatch":false,"sender":{"key":"dunpealer@gmail.com","avatar":"https://gravatar.com/avatar/42f3e6a1166eb44e33f24c20ccbe809fa8591413f366dfe3755c8a8d4935ace9?d=mp&s=160"},"body":"Hi. We tag our releases with names like \"release-0\", \"release-1\" and\nso forth. Tags (lightweight ones) seem like the perfect markers for\nthese releases since we want a reference that can't ever change (as\nopposed to a head).\n\nThe problem is that since there's no head pointing to each release, if\nour users just:\n\n$ git checkout release-1\n\nWhen they want to build that release, they get into a detached HEAD\nstate. I've always construed detached HEAD as a non-standard state,\nand it doesn't seem proper to reach it regularly in the course of a\nstandard operation like checking out past releases.\n\nIt's particularly confusing for our users who are new to Git.\n\nAny thoughts, or alternative methods to do this?\n\nThanks, D\n"},{"id":"156999","messageId":"20101201195125.GC27347@burratino","threadId":"25899","inReplyTo":"AANLkTi=b12n0J+Qg4S7i9dnbMHoWvPS3OXP0CDZevT_4@mail.gmail.com","subject":"Re: Proper way to checkout a tag?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-12-01T19:51:25Z","receivedAt":"2010-12-01T19:51:25Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nDun Peal wrote:\n\n> The problem is that since there's no head pointing to each release, if\n> our users just:\n> \n> $ git checkout release-1\n> \n> When they want to build that release, they get into a detached HEAD\n> state. I've always construed detached HEAD as a non-standard state,\n> and it doesn't seem proper to reach it regularly in the course of a\n> standard operation like checking out past releases.\n> \n> It's particularly confusing for our users who are new to Git.\n\nAny ideas for making the detached state more friendly?\n\nThe idea is this: when you check out a tag or a remote-tracking\nbranch, it is not to make changes to it.  Tags are unchanging,\nremote-tracking branches track remote state that the user does not\ndirectly control.  So what does it mean to check out such a thing?\n\nThere are two possibilities:\n\nIf you are checking out that commit to examine it, test it, maybe\nwrite a few one-off patches, then any work built from there does not\nneed to be remembered (except in the HEAD reflog, to avoid expensive\naccidents).  You can make an experiment permanent with\n\n\tgit checkout -b newbranch\n\nIf you are starting a new line of development, it needs to get a name.\nLong ago this was the only use case supported.  Even today it is often\na good way to go:\n\n\tgit checkout -b newbranch release-1\n\nHope that helps.\nJonathan\n"},{"id":"157010","messageId":"AANLkTim=0dqH=gqbM1xQOWQPCZb78wfsn9wf5WRJJ9vt@mail.gmail.com","threadId":"25899","inReplyTo":"20101201195125.GC27347@burratino","subject":"Re: Proper way to checkout a tag?","fromName":"Dun Peal","fromEmail":"dunpealer@gmail.com","sentAt":"2010-12-01T20:16:37Z","receivedAt":"2010-12-01T20:16:37Z","isPatch":false,"sender":{"key":"dunpealer@gmail.com","avatar":"https://gravatar.com/avatar/42f3e6a1166eb44e33f24c20ccbe809fa8591413f366dfe3755c8a8d4935ace9?d=mp&s=160"},"body":"On Wed, Dec 1, 2010 at 1:51 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:\n> The idea is this: when you check out a tag or a remote-tracking\n> branch, it is not to make changes to it.  Tags are unchanging,\n> remote-tracking branches track remote state that the user does not\n> directly control.\n\nYes, users checkout a release tag just so they can build parts of it.\nThere's definitely no intention of creating new changes on top of\nthem, and if there is then it should properly be a head (branch).\n\nI guess that's exactly the use-case for detached HEAD, so I guess the\nanswer is that we should all stop being afraid of that superficially\nscary term.\n\nThanks, D\n"},{"id":"157093","messageId":"4CF759CE.5010705@drmicha.warpmail.net","threadId":"25899","inReplyTo":"AANLkTim=0dqH=gqbM1xQOWQPCZb78wfsn9wf5WRJJ9vt@mail.gmail.com","subject":"Re: Proper way to checkout a tag?","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-12-02T08:33:18Z","receivedAt":"2010-12-02T08:33:18Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Dun Peal venit, vidit, dixit 01.12.2010 21:16:\n> On Wed, Dec 1, 2010 at 1:51 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:\n>> The idea is this: when you check out a tag or a remote-tracking\n>> branch, it is not to make changes to it.  Tags are unchanging,\n>> remote-tracking branches track remote state that the user does not\n>> directly control.\n> \n> Yes, users checkout a release tag just so they can build parts of it.\n> There's definitely no intention of creating new changes on top of\n> them, and if there is then it should properly be a head (branch).\n> \n> I guess that's exactly the use-case for detached HEAD, so I guess the\n> answer is that we should all stop being afraid of that superficially\n> scary term.\n\nIt's really one of the most useful features of git (as Jonathan\nexplained). There are two things which make it scary:\n\n- The name. We could call it differently (free head, unbound head,\nbranchless head, west coast head...).\n\n- The garbage collection. It's easy to commit on top of a detached head\nby mistake, and once you switch away from that, it's difficult to find\nit again (reflog) and easy to lose (gc/prune).\n\nThough the \"throw-away\" nature of detached heads is a useful feature, we\ncould possibly help users who commit on top of them better.\n\nMichael\n"}]}