{"thread":{"id":"12686","subject":"About detached heads","startedAt":"2008-03-14T09:46:07Z","lastAt":"2008-03-15T02:03:08Z","messageCount":22,"participants":["Geoff Russell","Jonathan del Strother","Wincent Colaiuta","David Kågedal","Matthieu Moy","Jakub Narebski","Sergei Organov","Adam Piatyszek","Chris Shoemaker","Rafael Garcia-Suarez","Nicolas Pitre","Linus Torvalds","Björn Steinbrink","Sean"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"72052","messageId":"93c3eada0803140246k53408c74m21f9dc277857202d@mail.gmail.com","threadId":"12686","inReplyTo":null,"subject":"About detached heads","fromName":"Geoff Russell","fromEmail":"geoffrey.russell@gmail.com","sentAt":"2008-03-14T09:46:07Z","receivedAt":"2008-03-14T09:46:07Z","isPatch":false,"sender":{"key":"geoffrey.russell@gmail.com","avatar":"https://gravatar.com/avatar/c30f497ccfa6bf06d86f30bd2ba092a2dd124c61c6bc902f7cb5c3f6486947de?d=mp&s=160"},"body":"This should be simple! I have a series of commits:\n\n 1---2---3---4---5\n\nI want to go back to 3 but not branch, so I want\n\n 1---2---3---4---5---3\n\n?\n\n git checkout 3...\n\ngets me the commit on a detached head, but I don't know how to put this back\nas the HEAD.\n\nI'm on git 1.5.0.5\n\nCheers,\nGeoff Russell\n"},{"id":"72053","messageId":"57518fd10803140251v425a0fa3ud11687a5043806cc@mail.gmail.com","threadId":"12686","inReplyTo":"93c3eada0803140246k53408c74m21f9dc277857202d@mail.gmail.com","subject":"Re: About detached heads","fromName":"Jonathan del Strother","fromEmail":"maillist@steelskies.com","sentAt":"2008-03-14T09:51:43Z","receivedAt":"2008-03-14T09:51:43Z","isPatch":false,"sender":{"key":"jon.delstrother@bestbefore.tv","avatar":"https://gravatar.com/avatar/754e21ab701c00e2d21fc261187254c34b2a1c0b959d9ee5be1a295990be3081?d=mp&s=160"},"body":"On Fri, Mar 14, 2008 at 9:46 AM, Geoff Russell\n wrote:\n> This should be simple! I have a series of commits:\n>\n> 1---2---3---4---5\n>\n> I want to go back to 3 but not branch, so I want\n>\n> 1---2---3---4---5---3\n>\n> ?\n>\n> git checkout 3...\n>\n> gets me the commit on a detached head, but I don't know how to put this back\n> as the HEAD.\n\n\nTwo options. Either rewrite history, nuking commits 4 & 5 :\n git reset --hard 3\n\nor publicly reverse the changes introduced by 5 & 4 :\n git revert 5\n git revert 4\n\nJon\n"},{"id":"72056","messageId":"9A4AC53D-BCFA-4BEE-BD53-AA7F29781454@wincent.com","threadId":"12686","inReplyTo":"93c3eada0803140246k53408c74m21f9dc277857202d@mail.gmail.com","subject":"Re: About detached heads","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2008-03-14T10:15:11Z","receivedAt":"2008-03-14T10:15:11Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 14/3/2008, a las 10:46, Geoff Russell escribió:\n\n> This should be simple! I have a series of commits:\n>\n> 1---2---3---4---5\n>\n> I want to go back to 3 but not branch, so I want\n>\n> 1---2---3---4---5---3\n>\n> ?\n>\n> git checkout 3...\n>\n> gets me the commit on a detached head, but I don't know how to put \n> this back\n> as the HEAD.\n>\n> I'm on git 1.5.0.5\n\nHow about?\n\n git cherry-pick the-sha-1-id-of-commit-3\n\nWincent\n"},{"id":"72058","messageId":"87iqzpfv3l.fsf@lysator.liu.se","threadId":"12686","inReplyTo":"57518fd10803140251v425a0fa3ud11687a5043806cc@mail.gmail.com","subject":"Re: About detached heads","fromName":"David Kågedal","fromEmail":"davidk@lysator.liu.se","sentAt":"2008-03-14T10:39:10Z","receivedAt":"2008-03-14T10:39:10Z","isPatch":false,"sender":{"key":"davidk@lysator.liu.se","avatar":"https://avatars.githubusercontent.com/u/60530?v=4"},"body":"\"Jonathan del Strother\" writes:\n\n> On Fri, Mar 14, 2008 at 9:46 AM, Geoff Russell\n> wrote:\n>> This should be simple! I have a series of commits:\n>>\n>> 1---2---3---4---5\n>>\n>> I want to go back to 3 but not branch, so I want\n>>\n>> 1---2---3---4---5---3\n>>\n>> ?\n>>\n>> git checkout 3...\n>>\n>> gets me the commit on a detached head, but I don't know how to put this back\n>> as the HEAD.\n>\n>\n> Two options. Either rewrite history, nuking commits 4 & 5 :\n> git reset --hard 3\n>\n> or publicly reverse the changes introduced by 5 & 4 :\n> git revert 5\n> git revert 4\n\nThe revert can be done by resetting to the tree in 3:\n\n git checkout 3 -- .\n git commit -m \"reset to 3\"\n\n-- \nDavid Kågedal\n"},{"id":"72060","messageId":"vpq1w6dvaxe.fsf@bauges.imag.fr","threadId":"12686","inReplyTo":"9A4AC53D-BCFA-4BEE-BD53-AA7F29781454@wincent.com","subject":"Re: About detached heads","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2008-03-14T10:48:13Z","receivedAt":"2008-03-14T10:48:13Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Wincent Colaiuta writes:\n\n> El 14/3/2008, a las 10:46, Geoff Russell escribió:\n>\n>> This should be simple! I have a series of commits:\n>>\n>> 1---2---3---4---5\n>>\n>> I want to go back to 3 but not branch, so I want\n>>\n>> 1---2---3---4---5---3\n>\n> How about?\n>\n> git cherry-pick the-sha-1-id-of-commit-3\n\nCorrect me if I'm wrong, but I believe this will try to re-apply\ncommit 3 (probably a no-op since commit 3 is already in the history,\nperhaps tons of conflicts if 4 and 5 touched the same pieces of code).\n\nThe OP wants to keep commit 3, and to revert commits 4 and 5. As\nmentionned in other messages, either \"git revert\" 4 and 5, or just\ncommit a new revision with the same tree as 3 had.\n\n-- \nMatthieu\n"},{"id":"72061","messageId":"m3lk4ly3vy.fsf@localhost.localdomain","threadId":"12686","inReplyTo":"93c3eada0803140246k53408c74m21f9dc277857202d@mail.gmail.com","subject":"Re: About detached heads","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-03-14T10:52:14Z","receivedAt":"2008-03-14T10:52:14Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"\"Geoff Russell\" writes:\n\n> This should be simple! I have a series of commits:\n> \n> 1---2---3---4---5\n> \n> I want to go back to 3 but not branch, so I want\n> \n> 1---2---3---4---5---3\n> \n> ?\n> \n> git checkout 3...\n> \n> gets me the commit on a detached head, but I don't know how to put this back\n> as the HEAD.\n\nLets check what git does in each of scenarios. Let's assume that\ncurrent branch is named 'master'.\n\nAt beginning we have:\n\n 1---2---3---4---5 <--- master <--- HEAD\n\nHEAD contents is \"ref: refs/heads/master\"\n\n1. Now, \"git checkout 3...\", which is equivalent to \"git checkout 3\",\ndetaches HEAD because commit '3' is not a head (is not a branch), so\nwe have:\n\n 1---2---3---4---5 <--- master\n ^\n \\ \n \\-------------- HEAD\n\nHEAD contents is \"\"\n\n\n2. If we did \"git reset --hard 3\" we would rewind the history,\nresulting in the following situation:\n\n 1---2---3 <--- master <--- HEAD\n \\ \n \\-4---5 <... master@{1}, ORIG_HEAD, HEAD@{1}\n \nand now commits 4 and 5 are referenced only by reflogs, and by the\n(temporary) \"last position of HEAD\" reference named ORIG_HEAD.\n\n\n3. Now, if you have published 1..5 history you would not want\n(usually) to rewind published branch. If you do the following:\n\n $ git revert --no-commit 5\n $ git revert 4\n\nyou would get the following:\n\n 1---2---3---4---5---(5^-1 4^-1 => 3) <--- master <--- HEAD\n\ngit-revert applies reversal of changes in given commit, in the \n\"patch -R\" (\"patch --reverse\") sense. Using '--no-commit' option\nallows to squash reverting two commits into one commit. The ordering\nof reverting ensures that there are no merge conflicts.\n\n\n4. Or you can just put the _contents_ of revision 3 into your working\ntree, either using plumbing command git-read-tree, or by checking out\nor resetting to top tree: \"git checkout 3^{tree}\", or \n\"git checkout 3 -- .\", or equivalent git-reset invocation.\n\nThis way you would get exactly\n\n 1---2---3---4---5---3 <--- master <--- HEAD\n\nbut the relation of 5---3 parentage is unclear: you would have to\nexplain it in the commit mesage.\n\nHTH\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"72064","messageId":"E1DAC955-38CC-495B-9DCA-B25847EFF6C4@wincent.com","threadId":"12686","inReplyTo":"vpq1w6dvaxe.fsf@bauges.imag.fr","subject":"Re: About detached heads","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2008-03-14T11:17:05Z","receivedAt":"2008-03-14T11:17:05Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 14/3/2008, a las 11:48, Matthieu Moy escribió:\n\n> Wincent Colaiuta writes:\n>\n>> El 14/3/2008, a las 10:46, Geoff Russell escribió:\n>>\n>>> This should be simple! I have a series of commits:\n>>>\n>>> 1---2---3---4---5\n>>>\n>>> I want to go back to 3 but not branch, so I want\n>>>\n>>> 1---2---3---4---5---3\n>>\n>> How about?\n>>\n>> git cherry-pick the-sha-1-id-of-commit-3\n>\n> Correct me if I'm wrong, but I believe this will try to re-apply\n> commit 3 (probably a no-op since commit 3 is already in the history,\n> perhaps tons of conflicts if 4 and 5 touched the same pieces of code).\n\nI thought the OP was saying that 4 and 5 somehow undid the effect of 3 \nand he wanted to reapply it. But he probably meant what you said, he \njust wants to reset back to 3.\n\nWincent\n"},{"id":"72068","messageId":"87lk4lo60k.fsf@osv.gnss.ru","threadId":"12686","inReplyTo":"m3lk4ly3vy.fsf@localhost.localdomain","subject":"Re: About detached heads","fromName":"Sergei Organov","fromEmail":"osv@javad.com","sentAt":"2008-03-14T12:16:11Z","receivedAt":"2008-03-14T12:16:11Z","isPatch":false,"sender":{"key":"osv@javad.com","avatar":null},"body":"Jakub Narebski writes:\n\n[...]\n\n> 3. Now, if you have published 1..5 history you would not want\n> (usually) to rewind published branch. If you do the following:\n>\n> $ git revert --no-commit 5\n\nthe working tree in now dirty...\n\n> $ git revert 4\n\nand this one fails with dirty tree :(\n\nProbably:\n\n$ git revert -n 5 && git revert -n 4 && git commit -a\n\n\nBTW, why git-revert doesn't take a range? Is there some fundamental\nproblem with it?\n\n-- Sergei.\n"},{"id":"72071","messageId":"47DA6F89.3080609@users.sourceforge.net","threadId":"12686","inReplyTo":"m3lk4ly3vy.fsf@localhost.localdomain","subject":"Re: About detached heads","fromName":"Adam Piatyszek","fromEmail":"ediap@users.sourceforge.net","sentAt":"2008-03-14T12:28:57Z","receivedAt":"2008-03-14T12:28:57Z","isPatch":false,"sender":{"key":"ediap@users.sourceforge.net","avatar":null},"body":"* Jakub Narebski [14 III 2008 11:52]:\n > Lets check what git does in each of scenarios. Let's assume that\n > current branch is named 'master'.\n >\n > At beginning we have:\n >\n > 1---2---3---4---5 <--- master <--- HEAD\n >\n > HEAD contents is \"ref: refs/heads/master\"\n >\n > 1. Now, \"git checkout 3...\", which is equivalent to \"git checkout 3\",\n > detaches HEAD because commit '3' is not a head (is not a branch), so\n > we have:\n >\n > 1---2---3---4---5 <--- master\n > ^\n > \\\n > \\-------------- HEAD\n >\n > HEAD contents is \"\"\n >\n >\n > 2. If we did \"git reset --hard 3\" we would rewind the history,\n > resulting in the following situation:\n >\n > 1---2---3 <--- master <--- HEAD\n > \\\n > \\-4---5 <... master@{1}, ORIG_HEAD, HEAD@{1}\n >\n > and now commits 4 and 5 are referenced only by reflogs, and by the\n > (temporary) \"last position of HEAD\" reference named ORIG_HEAD.\n >\n >\n > 3. Now, if you have published 1..5 history you would not want\n > (usually) to rewind published branch. If you do the following:\n >\n > $ git revert --no-commit 5\n > $ git revert 4\n >\n > you would get the following:\n >\n > 1---2---3---4---5---(5^-1 4^-1 => 3) <--- master <--- HEAD\n >\n > git-revert applies reversal of changes in given commit, in the\n > \"patch -R\" (\"patch --reverse\") sense. Using '--no-commit' option\n > allows to squash reverting two commits into one commit. The ordering\n > of reverting ensures that there are no merge conflicts.\n >\n >\n > 4. Or you can just put the _contents_ of revision 3 into your working\n > tree, either using plumbing command git-read-tree, or by checking out\n > or resetting to top tree: \"git checkout 3^{tree}\", or\n > \"git checkout 3 -- .\", or equivalent git-reset invocation.\n >\n > This way you would get exactly\n >\n > 1---2---3---4---5---3 <--- master <--- HEAD\n >\n > but the relation of 5---3 parentage is unclear: you would have to\n > explain it in the commit mesage.\n\nI suggest one should add the above nice explanation to FAQ or some wiki \nmaterial.\n\nBR,\n/Adam\n\n-- \n.:. Adam Piatyszek (ediap) .:.....................................:.\n.:. ediap@users.sourceforge.net .:................................:.\n"},{"id":"72087","messageId":"20080314134205.GA19674@pe.Belkin","threadId":"12686","inReplyTo":"m3lk4ly3vy.fsf@localhost.localdomain","subject":"Re: About detached heads","fromName":"Chris Shoemaker","fromEmail":"c.shoemaker@cox.net","sentAt":"2008-03-14T13:42:05Z","receivedAt":"2008-03-14T13:42:05Z","isPatch":false,"sender":{"key":"c.shoemaker@cox.net","avatar":null},"body":"On Fri, Mar 14, 2008 at 03:52:14AM -0700, Jakub Narebski wrote:\n> \"Geoff Russell\" writes:\n> \n> > This should be simple! I have a series of commits:\n> > \n> > 1---2---3---4---5\n> > \n> > I want to go back to 3 but not branch, so I want\n> > \n> > 1---2---3---4---5---3\n> > \n> > ?\n> > \n> > git checkout 3...\n> > \n> > gets me the commit on a detached head, but I don't know how to put this back\n> > as the HEAD.\n> \n> Lets check what git does in each of scenarios. Let's assume that\n> current branch is named 'master'.\n> \n> At beginning we have:\n> \n> 1---2---3---4---5 <--- master <--- HEAD\n> \n> HEAD contents is \"ref: refs/heads/master\"\n> \n> 1. Now, \"git checkout 3...\", which is equivalent to \"git checkout 3\",\n> detaches HEAD because commit '3' is not a head (is not a branch), so\n> we have:\n> \n> 1---2---3---4---5 <--- master\n> ^\n> \\ \n> \\-------------- HEAD\n> \n> HEAD contents is \"\"\n> \n> \n> 2. If we did \"git reset --hard 3\" we would rewind the history,\n> resulting in the following situation:\n> \n> 1---2---3 <--- master <--- HEAD\n> \\ \n> \\-4---5 <... master@{1}, ORIG_HEAD, HEAD@{1}\n> \n> and now commits 4 and 5 are referenced only by reflogs, and by the\n> (temporary) \"last position of HEAD\" reference named ORIG_HEAD.\n> \n> \n> 3. Now, if you have published 1..5 history you would not want\n> (usually) to rewind published branch. If you do the following:\n> \n> $ git revert --no-commit 5\n> $ git revert 4\n> \n> you would get the following:\n> \n> 1---2---3---4---5---(5^-1 4^-1 => 3) <--- master <--- HEAD\n> \n> git-revert applies reversal of changes in given commit, in the \n> \"patch -R\" (\"patch --reverse\") sense. Using '--no-commit' option\n> allows to squash reverting two commits into one commit. The ordering\n> of reverting ensures that there are no merge conflicts.\n> \n> \n> 4. Or you can just put the _contents_ of revision 3 into your working\n> tree, either using plumbing command git-read-tree, or by checking out\n> or resetting to top tree: \"git checkout 3^{tree}\", or \n> \"git checkout 3 -- .\", or equivalent git-reset invocation.\n> \n> This way you would get exactly\n> \n> 1---2---3---4---5---3 <--- master <--- HEAD\n> \n> but the relation of 5---3 parentage is unclear: you would have to\n> explain it in the commit mesage.\n\n[Great explanation. Let me offer one minor clarification:]\n\n This way you would get exactly:\n \n 1---2---3---4---5---3' <--- master <--- HEAD\n \n While the 3' commit has the same contents as 3, it is a new, distinct\n commit with its own history. Its commit message should explain why\n you want to go from 5 back to the contents of 3.\n\n-chris\n"},{"id":"72089","messageId":"b77c1dce0803140753w21515021u4541796d6e6934b@mail.gmail.com","threadId":"12686","inReplyTo":"20080314134205.GA19674@pe.Belkin","subject":"Re: About detached heads","fromName":"Rafael Garcia-Suarez","fromEmail":"rgarciasuarez@gmail.com","sentAt":"2008-03-14T14:53:52Z","receivedAt":"2008-03-14T14:53:52Z","isPatch":false,"sender":{"key":"rgarciasuarez@gmail.com","avatar":null},"body":"On 14/03/2008, Chris Shoemaker wrote:\n> This way you would get exactly:\n>\n> 1---2---3---4---5---3' <--- master <--- HEAD\n>\n>\n> While the 3' commit has the same contents as 3, it is a new, distinct\n> commit with its own history. Its commit message should explain why\n> you want to go from 5 back to the contents of 3.\n\nJust a small question -- does that mean that 3 and 3' share the same\ntree object ?\n"},{"id":"72092","messageId":"alpine.LFD.1.00.0803141117040.2947@xanadu.home","threadId":"12686","inReplyTo":"b77c1dce0803140753w21515021u4541796d6e6934b@mail.gmail.com","subject":"Re: About detached heads","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2008-03-14T15:19:37Z","receivedAt":"2008-03-14T15:19:37Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 14 Mar 2008, Rafael Garcia-Suarez wrote:\n\n> On 14/03/2008, Chris Shoemaker wrote:\n> > This way you would get exactly:\n> >\n> > 1---2---3---4---5---3' <--- master <--- HEAD\n> >\n> >\n> > While the 3' commit has the same contents as 3, it is a new, distinct\n> > commit with its own history. Its commit message should explain why\n> > you want to go from 5 back to the contents of 3.\n> \n> Just a small question -- does that mean that 3 and 3' share the same\n> tree object ?\n\nYes. However, they don't share the same parent in the commit object, so \neven if the commit text was the same and the time stamps were forced to \nbe the same, the commit 3' won't have the same SHA1.\n\n\nNicolas\n"},{"id":"72093","messageId":"200803141621.48321.jnareb@gmail.com","threadId":"12686","inReplyTo":"b77c1dce0803140753w21515021u4541796d6e6934b@mail.gmail.com","subject":"Re: About detached heads","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-03-14T15:21:47Z","receivedAt":"2008-03-14T15:21:47Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Fri, 14 Mar 2008, Rafael Garcia-Suarez wrote:\n> On 14/03/2008, Chris Shoemaker wrote:\n>>\n>> This way you would get exactly:\n>>\n>> 1---2---3---4---5---3' <--- master <--- HEAD\n>>\n>>\n>> While the 3' commit has the same contents as 3, it is a new, distinct\n>> commit with its own history. Its commit message should explain why\n>> you want to go from 5 back to the contents of 3.\n> \n> Just a small question -- does that mean that 3 and 3' share the same\n> tree object ?\n\nYes it does. \n\nCommit object has link to a tree object in the form\nof its sha1 id, and repository's object store is content addressed,\nor to be more exact sha-1 id of contents addressed.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"72123","messageId":"alpine.LFD.1.00.0803141041080.3557@woody.linux-foundation.org","threadId":"12686","inReplyTo":"93c3eada0803140246k53408c74m21f9dc277857202d@mail.gmail.com","subject":"Re: About detached heads","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-03-14T17:53:25Z","receivedAt":"2008-03-14T17:53:25Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 14 Mar 2008, Geoff Russell wrote:\n>\n> This should be simple! I have a series of commits:\n> \n> 1---2---3---4---5\n> \n> I want to go back to 3 but not branch, so I want\n> \n> 1---2---3---4---5---3\n\nThis is actually an uncommonly easy operation for core git, but it's a \nvery unusual thing to want to do in general, so I don't think there is any \nhigh-level command to do it directly. But it's really easy to do with \na single so-called \"plumbing\" command, namely \"git read-tree\".\n\nSo the \"core git\" way to do it is to literally just do\n\n\tgit read-tree -u -m 3\n\tgit commit\n\n(or use \"--reset\" instead of \"-m\" if you want to do it even in the \npresense unmerged entries).\n\nWhat the above does is to literally just read the tree state at \"3\", and \nmake it the new index: the \"-u\" means that we also want to update the \nworking tree to that state, and the \"-m\" means that we will merge in the \nold index stat information.\n\nThe commit then will then create the actual new commit: it will have the \nexact same tree as your commit '3', but it will be a new commit (so call \nit 3').\n\nOf course, people have already pointed out that another easy way to do it \nis to just revert 5 and 4. That may be the more high-level way to do it, \nbut the git-read-tree approach actually has the advantage that it will \nwork even across merges etc, and it will be very unambiguous: we want \n*exactly* the state at commit 3 back, nothing else.\n\n\t\t\tLinus\n"},{"id":"72126","messageId":"20080314183731.GA2994@atjola.homenet","threadId":"12686","inReplyTo":"alpine.LFD.1.00.0803141041080.3557@woody.linux-foundation.org","subject":"Re: About detached heads","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2008-03-14T18:37:31Z","receivedAt":"2008-03-14T18:37:31Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2008.03.14 10:53:25 -0700, Linus Torvalds wrote:\n> \n> \n> On Fri, 14 Mar 2008, Geoff Russell wrote:\n> >\n> > This should be simple! I have a series of commits:\n> > \n> > 1---2---3---4---5\n> > \n> > I want to go back to 3 but not branch, so I want\n> > \n> > 1---2---3---4---5---3\n> \n> This is actually an uncommonly easy operation for core git, but it's a \n> very unusual thing to want to do in general, so I don't think there is any \n> high-level command to do it directly. But it's really easy to do with \n> a single so-called \"plumbing\" command, namely \"git read-tree\".\n> \n> So the \"core git\" way to do it is to literally just do\n> \n> \tgit read-tree -u -m 3\n> \tgit commit\n> \n> (or use \"--reset\" instead of \"-m\" if you want to do it even in the \n> presense unmerged entries).\n> \n> What the above does is to literally just read the tree state at \"3\", and \n> make it the new index: the \"-u\" means that we also want to update the \n> working tree to that state, and the \"-m\" means that we will merge in the \n> old index stat information.\n> \n> The commit then will then create the actual new commit: it will have the \n> exact same tree as your commit '3', but it will be a new commit (so call \n> it 3').\n> \n> Of course, people have already pointed out that another easy way to do it \n> is to just revert 5 and 4. That may be the more high-level way to do it, \n> but the git-read-tree approach actually has the advantage that it will \n> work even across merges etc, and it will be very unambiguous: we want \n> *exactly* the state at commit 3 back, nothing else.\n\nHm, that's just squashing revert commit. Squashing can be done via:\ngit reset --soft HEAD~5 # Or wherever your squashed commit should start\ngit commit -m \"Squashed from HEAD~5 onwards\"\n\nNow the \"revert\" version of that:\ngit reset --hard HEAD~5 # Go back to the state that we want\ngit reset --soft ORIG_HEAD # Move HEAD back, but keep the index as is\ngit commit -m \"Back at the state of HEAD~5\"\n\nAFAICT that should have the same advantages as using read-tree, but\ndoesn't feel so low-level :-)\n\nBjörn\n"},{"id":"72129","messageId":"alpine.LFD.1.00.0803141150070.3557@woody.linux-foundation.org","threadId":"12686","inReplyTo":"20080314183731.GA2994@atjola.homenet","subject":"Re: About detached heads","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-03-14T18:51:20Z","receivedAt":"2008-03-14T18:51:20Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 14 Mar 2008, Bj?rn Steinbrink wrote:\n> \n> Hm, that's just squashing revert commit. Squashing can be done via:\n> git reset --soft HEAD~5 # Or wherever your squashed commit should start\n> git commit -m \"Squashed from HEAD~5 onwards\"\n> \n> Now the \"revert\" version of that:\n> git reset --hard HEAD~5 # Go back to the state that we want\n> git reset --soft ORIG_HEAD # Move HEAD back, but keep the index as is\n> git commit -m \"Back at the state of HEAD~5\"\n> \n> AFAICT that should have the same advantages as using read-tree, but\n> doesn't feel so low-level :-)\n\nUmm. The low-level one is a *lot* easier to understand than your \n\"high-level\" one, wouldn't you say?\n\nAnd when the low-level plumbing commands are easier, are they not then \nbetter porcelain?\n\n\t\tLinus\n"},{"id":"72130","messageId":"m34pb9xgrp.fsf@localhost.localdomain","threadId":"12686","inReplyTo":"alpine.LFD.1.00.0803141150070.3557@woody.linux-foundation.org","subject":"Re: About detached heads","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-03-14T19:11:33Z","receivedAt":"2008-03-14T19:11:33Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Linus Torvalds writes:\n\n> On Fri, 14 Mar 2008, Bjorn Steinbrink wrote:\n>> On 2008.03.14 10:53:25 -0700, Linus Torvalds wrote:\n>>> \n>>> So the \"core git\" way to do it is to literally just do\n>>> \n>>> \tgit read-tree -u -m 3\n>>> \tgit commit\n>>> \n>>> (or use \"--reset\" instead of \"-m\" if you want to do it even in the \n>>> presense unmerged entries).\n>>> \n>> \n>> Hm, that's just squashing revert commit. Squashing can be done via:\n>> git reset --soft HEAD~5 # Or wherever your squashed commit should start\n>> git commit -m \"Squashed from HEAD~5 onwards\"\n>> \n>> Now the \"revert\" version of that:\n>> git reset --hard HEAD~5 # Go back to the state that we want\n>> git reset --soft ORIG_HEAD # Move HEAD back, but keep the index as is\n>> git commit -m \"Back at the state of HEAD~5\"\n>> \n>> AFAICT that should have the same advantages as using read-tree, but\n>> doesn't feel so low-level :-)\n> \n> Umm. The low-level one is a *lot* easier to understand than your \n> \"high-level\" one, wouldn't you say?\n> \n> And when the low-level plumbing commands are easier, are they not then \n> better porcelain?\n\nAFAIK the porcelain equivalent to plumbing\n\n git read-tree -u -m 3\n\nis just\n\n git checkout 3 -- .\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"72132","messageId":"BAYC1-PASMTP1563DCF0556F09CFE67BE8AE0A0@CEZ.ICE","threadId":"12686","inReplyTo":"m34pb9xgrp.fsf@localhost.localdomain","subject":"Re: About detached heads","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2008-03-14T19:17:16Z","receivedAt":"2008-03-14T19:17:16Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Fri, 14 Mar 2008 12:11:33 -0700 (PDT)\nJakub Narebski wrote:\n\n> AFAIK the porcelain equivalent to plumbing\n> \n> git read-tree -u -m 3\n> \n> is just\n> \n> git checkout 3 -- .\n\nHi Jakub,\n\n git checkout . won't remove paths, so you could end up with extra\nstate that didn't exist in the earlier commit.\n\nSean\n"},{"id":"72151","messageId":"93c3eada0803141643r2f2c4c56l9e59f2ee7b67a8ca@mail.gmail.com","threadId":"12686","inReplyTo":"BAYC1-PASMTP1563DCF0556F09CFE67BE8AE0A0@CEZ.ICE","subject":"Re: About detached heads","fromName":"Geoff Russell","fromEmail":"geoffrey.russell@gmail.com","sentAt":"2008-03-14T23:43:00Z","receivedAt":"2008-03-14T23:43:00Z","isPatch":false,"sender":{"key":"geoffrey.russell@gmail.com","avatar":"https://gravatar.com/avatar/c30f497ccfa6bf06d86f30bd2ba092a2dd124c61c6bc902f7cb5c3f6486947de?d=mp&s=160"},"body":"I thought my question was trivial, but judging by the number of answers, clearly\nnot!\n\nI understand \"git read-tree -u -m 3 ; git commit\" and it does exactly\nwhat I want.\n\nThe context where I want to use this is for users who update files,\ncan understand\n\"take me back to the state I was in at 4pm yesterday before I mucked up\nmy data\" but who don't want to know about merging, branching, topics, etc, etc,\nBut of course having taken them back to the 4pm commit, they then realise that\nthey really need the 6pm commit or perhaps the 3pm commit. So anything which\njust throws away commits would be risky.\n\nThe \"git read-tree -u -m 3; git commit\" allows me to present a simple\nstraight line\nview of the data, which is perfect for the people I'm dealing with.\n\nMany thanks to you all,\n\nCheers,\nGeoff Russell\n"},{"id":"72152","messageId":"m3zlt0x39k.fsf@localhost.localdomain","threadId":"12686","inReplyTo":"93c3eada0803141643r2f2c4c56l9e59f2ee7b67a8ca@mail.gmail.com","subject":"Re: About detached heads","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-03-15T00:03:10Z","receivedAt":"2008-03-15T00:03:10Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"\"Geoff Russell\" writes:\n\n> I thought my question was trivial, but judging by the number of\n> answers, clearly not!\n> \n> I understand \"git read-tree -u -m 3 ; git commit\" and it does exactly\n> what I want.\n> \n> The context where I want to use this is for users who update files,\n> can understand \"take me back to the state I was in at 4pm yesterday\n> before I mucked up my data\" but who don't want to know about\n> merging, branching, topics, etc, etc, But of course having taken\n> them back to the 4pm commit, they then realise that they really need\n> the 6pm commit or perhaps the 3pm commit. So anything which just\n> throws away commits would be risky.\n\nThanks to the reflog even if they go the \"git reset --hard 3\" route,\nthe commits would be protected for gc.reflogExpireUnreachable period,\nwhich defaults to 30 days, by reflog. After this period they could be\ngarbage-collected.\n\n> The \"git read-tree -u -m 3; git commit\" allows me to present a\n> simple straight line view of the data, which is perfect for the\n> people I'm dealing with.\n\nSimple, straight line with _rewinds_, i.e. not so simple history.\n\nUnless you can expect users to find errors later than 30 days, or you\nhave pushed non-rewritable branch already, then \"git reset --hard 3\"\nis IMHO a beter solution than \"git read-file -u -m 3 && git commit -a\".\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"72154","messageId":"alpine.LFD.1.00.0803142025080.2947@xanadu.home","threadId":"12686","inReplyTo":"93c3eada0803141643r2f2c4c56l9e59f2ee7b67a8ca@mail.gmail.com","subject":"Re: About detached heads","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2008-03-15T00:38:10Z","receivedAt":"2008-03-15T00:38:10Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Sat, 15 Mar 2008, Geoff Russell wrote:\n\n> The context where I want to use this is for users who update files,\n> can understand\n> \"take me back to the state I was in at 4pm yesterday before I mucked up\n> my data\" but who don't want to know about merging, branching, topics, etc, etc,\n> But of course having taken them back to the 4pm commit, they then realise that\n> they really need the 6pm commit or perhaps the 3pm commit. So anything which\n> just throws away commits would be risky.\n\nThe reflog can help you there as well. You can simply do:\n\n\tgit reset --hard HEAD@{yesterday.at.4pm}\n\nand it'll magically bring you back to the state you were yesterday at \n4pm. You need the 6pm state instead? No problem: just ask for \nyesterday.at.6pm then.\n\nAnd before doing the 'reset --hard', you might want to do a simple \n'checkout' beforehand so you can be sure it actually corresponds to what \nyou want:\n\n\tgit checkout HEAD@{yesterday.at.4pm}\n\t[compile, test, whatever]\n\tgit checkout HEAD@{yesterday.at.6pm}\n\t[compile, test, whatever]\n\nand when OK with it, then:\n\n\t# return to your master branch (or any other branch)\n\tgit checkout master\n\t# then reset it to the desired state\n\tgit reset --hard HEAD@{yesterday.at.6pm}\n\n\nNicolas\n"},{"id":"72156","messageId":"93c3eada0803141903p30184defk979247129a1cc6db@mail.gmail.com","threadId":"12686","inReplyTo":"alpine.LFD.1.00.0803142025080.2947@xanadu.home","subject":"Re: About detached heads","fromName":"Geoff Russell","fromEmail":"geoffrey.russell@gmail.com","sentAt":"2008-03-15T02:03:08Z","receivedAt":"2008-03-15T02:03:08Z","isPatch":false,"sender":{"key":"geoffrey.russell@gmail.com","avatar":"https://gravatar.com/avatar/c30f497ccfa6bf06d86f30bd2ba092a2dd124c61c6bc902f7cb5c3f6486947de?d=mp&s=160"},"body":"On 3/15/08, Nicolas Pitre wrote:\n> ...\n>\n> git reset --hard HEAD@{yesterday.at.4pm}\n>\n> and it'll magically bring you back to the state you were yesterday at\n> 4pm. You need the 6pm state instead? No problem: just ask for\n> yesterday.at.6pm then.\n>\n> And before doing the 'reset --hard', you might want to do a simple\n> 'checkout' beforehand so you can be sure it actually corresponds to what\n> you want:\n>\n> git checkout HEAD@{yesterday.at.4pm}\n> [compile, test, whatever]\n> git checkout HEAD@{yesterday.at.6pm}\n> [compile, test, whatever]\n>\n> and when OK with it, then:\n>\n> # return to your master branch (or any other branch)\n> git checkout master\n> # then reset it to the desired state\n> git reset --hard HEAD@{yesterday.at.6pm}\n>\n>\n>\n> Nicolas\n\nMore useful advice ... many thanks.\n\nCheers,\nGeoff.\n"}]}