{"thread":{"id":"27402","subject":"git -- how to revert build to as-originally-cloned?","startedAt":"2011-05-18T22:53:01Z","lastAt":"2011-05-20T14:42:34Z","messageCount":6,"participants":["John Lumby","Tim Mazid","Philippe Vaucher"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"168170","messageId":"4DD44DCD.7010508@hotmail.com","threadId":"27402","inReplyTo":null,"subject":"git -- how to revert build to as-originally-cloned?","fromName":"John Lumby","fromEmail":"johnlumby@hotmail.com","sentAt":"2011-05-18T22:53:01Z","receivedAt":"2011-05-18T22:53:01Z","isPatch":false,"sender":{"key":"johnlumby@hotmail.com","avatar":null},"body":"I am stuck trying to revert a private kernel build back to the state in \nwhich I originally cloned it,\n(after probably doing the wrong thing - as below). Hoping someone \ncan advise.\n\nHere's what I did (helpful criticism welcome)\n\nOn machine MA in filesystem /a on 13 May\n\ngit clone \ngit://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6.git\n\n(This build built ok and ran ok and is what I want back)\n\nA few days later on machine MB on filesystem /b - same git clone \ncommand but of course a slightly changed build.\n\nYesterday - I wanted to synch build a/ from b/ :\n git branch jel_r8169 /* made a new branch -- ok */\n nfs-mounted /b on MA\n git fetch file:///a/.../net-next-2.6/.git /* worked ok *\n git merge FETCH_HEAD /* worked ok and output \nlist of files : */\n output started with\nUpdating 72a8f97..1b1cb1f\nFast-forward\n then list of files\n output ended with\n 56 files changed, 3352 insertions(+), 886 deletions(-)\n create mode 100644 include/net/ping.h\n create mode 100644 net/ipv4/ping.c\n\nI then built this build and built ok but build is broken -\nunresolved syms in some modules - I want to undo my merge.\n\nI have tried all the commands I can find that claim to do this\nand none of them have done it, e.g. :\n git reset --hard HEAD /* did nothing */\n git reset --hard ORIG_HEAD /* did nothing */\n\nNot only that, but none of the various show , log , status commands\nappear to be aware of the merge at all. There appears to be no record \nof it -\nbut the actual files themselves are the updated ones. (diff with /b \ncompares equal)\n\nHow can I undo it?\n\nCheers John Lumby\n"},{"id":"168175","messageId":"SNT124-W3827431D13C320A4C9BF9DC48F0@phx.gbl","threadId":"27402","inReplyTo":"4DD44DCD.7010508@hotmail.com","subject":"RE: git -- how to revert build to as-originally-cloned?","fromName":"Tim Mazid","fromEmail":"timmazid@hotmail.com","sentAt":"2011-05-18T23:26:45Z","receivedAt":"2011-05-18T23:26:45Z","isPatch":false,"sender":{"key":"timmazid@hotmail.com","avatar":null},"body":"\n> Date: Wed, 18 May 2011 18:53:01 -0400\n> From: johnlumby@hotmail.com\n> To: git@vger.kernel.org\n> Subject: git -- how to revert build to as-originally-cloned?\n>\n> I am stuck trying to revert a private kernel build back to the state in\n> which I originally cloned it,\n> (after probably doing the wrong thing - as below). Hoping someone\n> can advise.\n>\n> Here's what I did (helpful criticism welcome)\n>\n> On machine MA in filesystem /a on 13 May\n>\n> git clone\n> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6.git\n>\n...\n>\n> I have tried all the commands I can find that claim to do this\n> and none of them have done it, e.g. :\n> git reset --hard HEAD /* did nothing */\n> git reset --hard ORIG_HEAD /* did nothing */\n>\n> Not only that, but none of the various show , log , status commands\n> appear to be aware of the merge at all. There appears to be no record\n> of it -\n> but the actual files themselves are the updated ones. (diff with /b\n> compares equal)\n>\n> How can I undo it?\n>\n> Cheers John Lumby\n\n\n\n\n\nYou should now have a merge commit. git log should show the latest \n\ncommit with a message similar to \"merge blah\".\n\n\n\nNormally in order to undo a merge, you would simply do a \"git reset\n\n--hard HEAD^\". Take note of the carat(is that correct?) character; that \n\nmeans the commit BEFORE head.\n\n\n\nCan you please post the commit message that you see in the first commit\n\nwhen doing a git log?\n\nAlso, if you just want to go back to a particular branch, you can\nspecify it to git reset, in the form of \"git reset --hard \norigin/master\". This will reset (discarding any changes) YOUR branch to\nwherever origin/master happens to be, which, from reading your message \nseems to be where you want to go?\n\nBe careful if you have made changes you want to keep, though.\n\n\n\n\nCheers,\n\nTim.\n\n\n\n\n\n() ascii ribbon campaign - against html e-mail\n\n/\\ www.asciiribbon.org - against proprietary attachments\n \t\t \t \t\t "},{"id":"168218","messageId":"4DD536EC.3060308@hotmail.com","threadId":"27402","inReplyTo":"SNT124-W3827431D13C320A4C9BF9DC48F0@phx.gbl","subject":"Re: git -- how to revert build to as-originally-cloned?","fromName":"John Lumby","fromEmail":"johnlumby@hotmail.com","sentAt":"2011-05-19T15:27:40Z","receivedAt":"2011-05-19T15:27:40Z","isPatch":false,"sender":{"key":"johnlumby@hotmail.com","avatar":null},"body":"On 05/18/11 19:26, Tim Mazid wrote:\n>> Date: Wed, 18 May 2011 18:53:01 -0400\n>> From: johnlumby@hotmail.com\n>> To: git@vger.kernel.org\n>> Subject: git -- how to revert build to as-originally-cloned?\n>>\n>> I am stuck trying to revert a private kernel build back to the state in\n>> which I originally cloned it,\n>\n>\n> Normally in order to undo a merge, you would simply do a \"git reset\n>\n> --hard HEAD^\". Take note of the carat(is that correct?) character; that\n>\n> means the commit BEFORE head.\n>\n>\n>\n> Can you please post the commit message that you see in the first commit\n>\n> when doing a git log?\n\nHere are the first three. I assume (not sure) they are what was merged \ninto the newer clone, /b, just before I cloned it\n\n------------------------------------------------------------------------------\ncommit 89c64d755fbf04d7541d526931dc4b38301946d1\nMerge: 4dc6ec2 4f6290c\nAuthor: David S. Miller \nDate: Sun May 15 01:08:23 2011 -0400\n\n Merge branch 'master' of \nmaster.kernel.org:/pub/scm/linux/kernel/git/jkirsher/net-next-2.6\n\ncommit 4dc6ec26fe7d9f89349d4c0c654e2f07420f4b27\nMerge: 7be799a ca06c6e\nAuthor: David S. Miller \nDate: Sat May 14 22:47:51 2011 -0400\n\n Merge branch 'batman-adv/next' of \ngit://git.open-mesh.org/ecsv/linux-merge\n\ncommit 5c5095494fb545f53b80cbb7539679a10a3472a6\nMerge: 4d586b8 def5768\nAuthor: David S. Miller \nDate: Thu May 12 23:01:55 2011 -0400\n------------------------------------------------------------------------------\n\nSo I now think I see the problem with using a reset based on something \nrelating to commits -\napparently (??) there is nothing in the git log to distinguish commits \ndone by my last merge versus commits prior to that. I.e. the \"merge\" \ndoes not appear to be logged as an event in its own right, only as the \ncommits inside it??\n> Also, if you just want to go back to a particular branch, you can\n> specify it to git reset, in the form of \"git reset --hard\n> origin/master\". This will reset (discarding any changes) YOUR branch to\n> wherever origin/master happens to be, which, from reading your message\n> seems to be where you want to go?\n\nAh - that did it, thanks Tim. I had seen that one but wasn't \nsure whether it would reset me back to what I cloned or the master of \nthat clone i.e. way back to the \"original\" origin of this build.\n\nIt seems if I had not created a separate branch -- I would now be \ncompletely sunk?\n\nIt would be nice if there was a \"git undo\" which undid whatever changes \nto files+index were made by the immediately preceding git command, \nwhatever it was and whatever it did.\n\n\n> Be careful if you have made changes you want to keep, though.\n\n\nNo worries there although thanks for the warning.\n"},{"id":"168289","messageId":"SNT124-W51D709B129B6A940ED17F2C4710@phx.gbl","threadId":"27402","inReplyTo":"4DD536EC.3060308@hotmail.com","subject":"RE: git -- how to revert build to as-originally-cloned?","fromName":"Tim Mazid","fromEmail":"timmazid@hotmail.com","sentAt":"2011-05-20T02:16:27Z","receivedAt":"2011-05-20T02:16:27Z","isPatch":false,"sender":{"key":"timmazid@hotmail.com","avatar":null},"body":"\nI think I'll just give a brief answer to each of your points, then give\nyou a wall of text at the end.\n\n\n> From: johnlumby@hotmail.com\n> On 05/18/11 19:26, Tim Mazid wrote:\n> > Normally in order to undo a merge, you would simply do a \"git reset\n> > --hard HEAD^\". Take note of the carat(is that correct?) character; that\n> > means the commit BEFORE head.\n\nHEAD points at the commit where you are checked out now.\nThe carat character '^' tells git to look at the commit BEFORE the one \nthat's specified.\nSee below.\n\n\n> > Can you please post the commit message that you see in the first commit\n> > when doing a git log?\n>\n> Here are the first three. I assume (not sure) they are what was merged\n> into the newer clone, /b, just before I cloned it\n>\n> ------------------------------------------------------------------------------\n> commit 89c64d755fbf04d7541d526931dc4b38301946d1\n> Merge branch 'master' of\n> master.kernel.org:/pub/scm/linux/kernel/git/jkirsher/net-next-2.6\n>\n> commit 4dc6ec26fe7d9f89349d4c0c654e2f07420f4b27\n> Merge branch 'batman-adv/next' of\n> git://git.open-mesh.org/ecsv/linux-merge\n>\n> commit 5c5095494fb545f53b80cbb7539679a10a3472a6\n> ------------------------------------------------------------------------------\n\nYou actually skipped the message of the third message there. :P\n\nBut I can see that the first two are actually merges. Were they both \nyour doing? If so, doing a git reset --hard HEAD^ will only take you\nback one commit.\nSee above, and then below.\n\n\n> So I now think I see the problem with using a reset based on something\n> relating to commits -\n> apparently (??) there is nothing in the git log to distinguish commits\n> done by my last merge versus commits prior to that. I.e. the \"merge\"\n> does not appear to be logged as an event in its own right, only as the\n> commits inside it??\n\nTwo points:\n - in git, you have commits and \"pointers to commits\"; and\n - the commit itself IS the merge.\nSee below.\n\n\n> > Also, if you just want to go back to a particular branch, you can\n> > specify it to git reset, in the form of \"git reset --hard\n> > origin/master\". This will reset (discarding any changes) YOUR branch to\n> > wherever origin/master happens to be, which, from reading your message\n> > seems to be where you want to go?\n>\n> Ah - that did it, thanks Tim. I had seen that one but wasn't\n> sure whether it would reset me back to what I cloned or the master of\n> that clone i.e. way back to the \"original\" origin of this build.\n>\n> It seems if I had not created a separate branch -- I would now be\n> completely sunk?\n\nYour branches are completely separate to the branches of other repos.\nSee below.\n\n\n> It would be nice if there was a \"git undo\" which undid whatever changes\n> to files+index were made by the immediately preceding git command,\n> whatever it was and whatever it did.\n\nI believe (speculation) that the reason this hasn't been done is that\nthere are too many things you can _DO_ in git in order to have a simple\n\"undo\" button. Compare it to having an \"undo\" button in real life; what\nand how much would it actually undo? There are simply too many different\nsituations to have something as simple as undo.\nHaving said that, there are ways to recover from almost every situation\nin git (most of which I'm yet to learn). See below.\n\n\n> > Be careful if you have made changes you want to keep, though.\n> No worries there although thanks for the warning.\n\nI've lost data a few times not thinking about what I was doing. :P\n\n\nAlright, so I promised you a crack at an explanation. List, please feel\nfree to chime in and correct me where I am mistaken.\n\nAll changes that you make to your repository are stored in what are\ncalled \"commits\"; these are, essentially diffs, and point to \"parent\"\nand \"child\" commits, so that you can trace a path along commits and see\nyour code change along the way.\n\nNow, branches and tags are actually \"pointers to commits\"[*] in a way.\nA branch or a tag in itself does not actually contain any changes or\ncode.  When you reference a branch or tag, you're actually referencing\nthe commit that they point to.\n\nWhen you create a tag, you give it a commit that it should point to (if\nyou do not provide a commit, it actually defaults to where you are now),\nand then the tag never changes. This is why it is useful for\n\"tagging\"[*] releases. You put it there and it will stay there so that\nother people can see it. In this way, it is permanent[*] (unless you\nreally want to delete it).\n\nBranches, however, are different; whenever you checkout a branch,\nwhatever you do, whether it may be resetting, creating new commits, or\nmerges, the branch follows you around, such that it records your actions\nas being part of that branch. So a branch will \"flow\"[*] over time as\nyou add more code. Thus, branches are semi-permanent[*], as the commits\nthey point to change, but they stay in the \"past\" of the branch.\n\nThings like HEAD and FETCH_HEAD are similar in that they too \"point at\ncommits\", but unlike branches (which are semi-permanent) and tags (which\nare permanent), they are temporary. HEAD moves around; a _lot_. What\nHEAD really does is point to the commit that you are checked out on.\nWhenever you switch branches, move around, make commits, merges, and\nwhatever else, HEAD keeps changing to point at the commit you are now\non, whether it be a previously existing one, or a newly created one.\n\nSo, in your repository, you have branches, and tags, and a bunch of\ntemporary pointers, such as HEAD. So does everybody else. How do you\ntell which is which?\n\nWell, that is why when I told you to git reset, I told you to tell it to\npoint to \"origin/master\". What that means is the pointer named \"master\"\non the remote repository called \"origin\". (More on remote repositories\nlater). If you had said \"git reset --hard master\" it actually would have\nreset you to _your_ master branch. If you were already checked out on\nmaster, you would've gone nowhere.\n\nSo, \"git reset --hard branch-name\" takes whatever branch you're on, and\nmakes it point to the same place as branch-name, which exists in your\nlocal repository.\nAs a corollary, \"git reset --hard remote-name/branch-name\" takes the\nbranch you're on, and makes it point to the same place as branch-name on\nthe _remote_ repository named remote-name. (More on remote repositories\nshortly).\n\nIf you were to do, however, \"git reset --hard HEAD\", you don't actually\nmove to anywhere; but what it does do, because you've supplied the\n\"--hard\" option, is *discards* _all_ changes made from the commit that\nHEAD points at. This means that if you have made any changes, but have\nnot committed them, they will be lost.\nThis is useful if you made some changes which you decide you don't need,\nor if you were merely testing something in your code. But use it with\ncaution, as you will _all_ changes; so if you made some changes, but\ndecided you didn't want to keep some, commit what you want to keep\nfirst.\n\nBut what if you did a merge or already committed some changes, and want\nto undo that? Well, that is where the modifiers[*] come in. The one\nyou've already been introduced to is the carat character (^). What this\nactually means is point to the commit _before_ the one referenced.\nSo, saying HEAD^ means the commit before HEAD. And because merges are\nactually commits, you can easily undo a merge by going to the commit\njust before it.\nYou can also chain carats together; HEAD^^^ means the commit *three*\nbefore where HEAD points.\nYou can also use carats for other commit references[*], such as branches\nand tags. Want to go to the commit just before v1.0 (for whatever\nreason)? No problem. Just do a \"git checkout v1.0^\".\n\nBut, what if you want to go to the commit ten or twenty before v1.0? The\nfirst thing I would say is that is far too specific without actually\nknowing where you're going and you should reconsider your strategy.\nHowever, if that is what you wish to do, you could easily stack twenty\ncarats together.\nYou can see that this would be very unwieldy; that is\nwhy git provides us with another modifier: the tilde (~). You must\nalways follow the tilde with a number. What it says is that you want to\ngo X commits before the referenced one. So, \"git checkout v1.0~17\" will\ntake you to the commit *17* before v1.0.\n\nI said before that that you have your local repository and the remote\nrepository. You can actually have any number of remote repositories\nreferenced. Initially, though, the only remote repository you have is\nthe one where you checked out from (unless you created a clean repo\nyourself).\nYou can add and remove remote repositories through the \"git remote\"\ncommand.\n\nYou were afraid about not creating a branch and being sunk. The\nimportant thing to realise is that whatever you do in _your_ repository\ndoes not affect the _remote_ repository. The information in the remote\nrepository will stay there until _they_ decide to change it. So the only\nway for you to affect the remote repository is for them to take what you\ndid and apply it to their repository.\n\nSecondly, even given that, your remote pointers (the origin/* pointers)\ncannot be changed by you. All you can do is remove them (you can add\nthem back at any point; this is not a loss) and synchronise[*] them with\nthe remote, if they've changed there.\n\nThis means that no matter what you did, unless you actually deleted the\norigin/master remote branch (which you could easily get back anyway),\nthe \"git reset --hard origin/master\" command will always take you back\nto your happy place, or, more correctly, where the remote was pointing\nits master branch to when you last synchronised.\n\nYou can view all the remote branches you can reference by using the \"git\nbranch -r\" command, without any arguments. You can also view all your\nlocal branches by using \"git branch\" (without the -r). It works\nsimilarly for \"git tag\".\n\nI hope I've covered everything you wanted. If not, there are plenty of\nresources, and you can always ask here.\n\nIt also helps to visualise these things, and there are several tools\nthat help you in this regard. The first is \"git log --graph\", which will\nshow you lines on the side, showing you how commits are connected.\nThen, there are a number of external programs. I personally use gitk,\nbut I know there are others, if it doesn't suit your tastes.\n\n\nAnd have a read through the documentation. You probably won't\nunderstand most of it the first time, but the more you read it, the more\nyou'll understand.\n\n\nGood luck,\nTim.\n\n() ascii ribbon campaign - against html e-mail\n/\\ www.asciiribbon.org - against proprietary attachments\n \t\t \t \t\t "},{"id":"168317","messageId":"4DD67798.4050503@hotmail.com","threadId":"27402","inReplyTo":"SNT124-W51D709B129B6A940ED17F2C4710@phx.gbl","subject":"Re: git -- how to revert build to as-originally-cloned?","fromName":"John Lumby","fromEmail":"johnlumby@hotmail.com","sentAt":"2011-05-20T14:15:52Z","receivedAt":"2011-05-20T14:15:52Z","isPatch":false,"sender":{"key":"johnlumby@hotmail.com","avatar":null},"body":"Tim, Thanks very much indeed for taking the time to provide all that \nexplanation. Very helpful.\nNot sure I have understood all of it but it makes more sense now.\n\nI will embed answers to specific questions you raised :\n\nOn 05/19/11 22:16, Tim Mazid wrote:\n>\n>>> Can you please post the commit message that you see in the first commit\n>>> when doing a git log?\n>> Here are the first three. I assume (not sure) they are what was merged\n>> into the newer clone, /b, just before I cloned it\n>>\n>> ------------------------------------------------------------------------------\n>> commit 89c64d755fbf04d7541d526931dc4b38301946d1\n>> Merge branch 'master' of\n>> master.kernel.org:/pub/scm/linux/kernel/git/jkirsher/net-next-2.6\n>>\n>> commit 4dc6ec26fe7d9f89349d4c0c654e2f07420f4b27\n>> Merge branch 'batman-adv/next' of\n>> git://git.open-mesh.org/ecsv/linux-merge\n>>\n>> commit 5c5095494fb545f53b80cbb7539679a10a3472a6\n>> ------------------------------------------------------------------------------\n> You actually skipped the message of the third message there. :P\n\nYou're right. as it happens, after the reset back to origin/master,\nthat third merge is now the first one shown in the log and it reads\n\ncommit 5c5095494fb545f53b80cbb7539679a10a3472a6\nMerge: 4d586b8 def5768\nAuthor: David S. Miller \nDate: Thu May 12 23:01:55 2011 -0400\n\n Merge branch 'master' of \nmaster.kernel.org:/pub/scm/linux/kernel/git/davem/net-next-2.6\n\n\n> But I can see that the first two are actually merges. Were they both\n> your doing? If so, doing a git reset --hard HEAD^ will only take you\n> back one commit.\n> See above, and then below.\n\nAh - I should have said that I selected only merges in my git log \ncommand -\ngit log --merges\n(With no qualifier, git log returns about 3.8 million lines / 150 \nMBytes, hard to work with)\nAnd, based on what the command now returns, it seems that the first \ntwo that I listed before\n(which are no longer present) were as a result of my (single) merge \ncommand, i.e. my merge\nresulted in merging :\n . two merges that were done by someone else in the master that I \ncloned into my /b filesystem,\n . maybe some other non-merge commits that I did not query before \nand now don't know\n\n>\n>> So I now think I see the problem with using a reset based on something\n>> relating to commits -\n>> apparently (??) there is nothing in the git log to distinguish commits\n>> done by my last merge versus commits prior to that. I.e. the \"merge\"\n>> does not appear to be logged as an event in its own right, only as the\n>> commits inside it??\n> Two points:\n> - in git, you have commits and \"pointers to commits\"; and\n> - the commit itself IS the merge.\n\nYou've lost me here. If a merge can consist of many commits, \nincluding other merges (see above),\nthen how can one commit be a merge? Note that in my original git log \n--merges output that I posted\nin my earlier post, i.e. the one before I reset, there was *no* record \nof *my* merge command itself,\nonly of the sub-merges that my merge dragged along. I think this is \nthe crucial (to me) point -\ngit did not record what I did, only the effects of what I did. Not \nsaying this is wrong or right,\nbut significant.\n\n> See below.\n>\n>\n>>> Also, if you just want to go back to a particular branch, you can\n>>> specify it to git reset, in the form of \"git reset --hard\n>>> origin/master\". This will reset (discarding any changes) YOUR branch to\n>>> wherever origin/master happens to be, which, from reading your message\n>>> seems to be where you want to go?\n>> Ah - that did it, thanks Tim. I had seen that one but wasn't\n>> sure whether it would reset me back to what I cloned or the master of\n>> that clone i.e. way back to the \"original\" origin of this build.\n>>\n>> It seems if I had not created a separate branch -- I would now be\n>> completely sunk?\n> Your branches are completely separate to the branches of other repos.\n\nAh, ok. Good.\n\n> See below.\n>\n>\n>> It would be nice if there was a \"git undo\" which undid whatever changes\n>> to files+index were made by the immediately preceding git command,\n>> whatever it was and whatever it did.\n> I believe (speculation) that the reason this hasn't been done is that\n> there are too many things you can _DO_ in git in order to have a simple\n> \"undo\" button. Compare it to having an \"undo\" button in real life; what\n> and how much would it actually undo? There are simply too many different\n> situations to have something as simple as undo.\n> Having said that, there are ways to recover from almost every situation\n> in git (most of which I'm yet to learn). See below.\n\nI see it would be a large and tedious thing to code, but I do think it \nwould be\nperfectly well-defined :\n\n gather all relevant information about the most recent git command \nthat changed\n either files or index or pointers, and reverse its effects.\n\nIn my particular case, with your insight, I can now see that it would \nhave been quite easy to delve into\nthe log and calculate how many carets or tildes I needed to revert back \nto the commit that\ncorresponded to my initial cloned state.\n\nIn a general case, I think this could easily be a complex burden for a \ndumb user to have to do\ncompared with \"undo what I just did\".\n\n\n>\n>>> Be careful if you have made changes you want to keep, though.\n>> No worries there although thanks for the warning.\n> I've lost data a few times not thinking about what I was doing. :P\n>\n>\n> Alright, so I promised you a crack at an explanation. List, please feel\n> free to chime in and correct me where I am mistaken.\n>\n>\nYes, I have used gitk and it helps a lot.\n\nThanks again John Lumby\n"},{"id":"168318","messageId":"BANLkTi=nFf_6oULwqtC=--JBS9py3fvjwA@mail.gmail.com","threadId":"27402","inReplyTo":"4DD44DCD.7010508@hotmail.com","subject":"Re: git -- how to revert build to as-originally-cloned?","fromName":"Philippe Vaucher","fromEmail":"philippe.vaucher@gmail.com","sentAt":"2011-05-20T14:42:34Z","receivedAt":"2011-05-20T14:42:34Z","isPatch":false,"sender":{"key":"philippe.vaucher@gmail.com","avatar":null},"body":"> am stuck trying to revert a private kernel build back to the state in which I originally cloned it,\n> (after probably doing the wrong thing  -  as below).     Hoping someone can advise.\n\nI just wanted to add that usually when I \"mess up\" and want to revert\nto a previous state, I usually simply `git reflog`, find where I was\nbefore messing up, then `git reset --hard` to the desired SHA1.\n\nHope it helps,\nPhilippe\n"}]}