From: John Lumby Date: Fri, 20 May 2011 14:15:52 GMT Subject: Re: git -- how to revert build to as-originally-cloned? Message-ID: <4DD67798.4050503@hotmail.com> In-Reply-To: Tim, Thanks very much indeed for taking the time to provide all that explanation. Very helpful. Not sure I have understood all of it but it makes more sense now. I will embed answers to specific questions you raised : On 05/19/11 22:16, Tim Mazid wrote: > >>> Can you please post the commit message that you see in the first commit >>> when doing a git log? >> Here are the first three. I assume (not sure) they are what was merged >> into the newer clone, /b, just before I cloned it >> >> ------------------------------------------------------------------------------ >> commit 89c64d755fbf04d7541d526931dc4b38301946d1 >> Merge branch 'master' of >> master.kernel.org:/pub/scm/linux/kernel/git/jkirsher/net-next-2.6 >> >> commit 4dc6ec26fe7d9f89349d4c0c654e2f07420f4b27 >> Merge branch 'batman-adv/next' of >> git://git.open-mesh.org/ecsv/linux-merge >> >> commit 5c5095494fb545f53b80cbb7539679a10a3472a6 >> ------------------------------------------------------------------------------ > You actually skipped the message of the third message there. :P You're right. as it happens, after the reset back to origin/master, that third merge is now the first one shown in the log and it reads commit 5c5095494fb545f53b80cbb7539679a10a3472a6 Merge: 4d586b8 def5768 Author: David S. Miller Date: Thu May 12 23:01:55 2011 -0400 Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-next-2.6 > But I can see that the first two are actually merges. Were they both > your doing? If so, doing a git reset --hard HEAD^ will only take you > back one commit. > See above, and then below. Ah - I should have said that I selected only merges in my git log command - git log --merges (With no qualifier, git log returns about 3.8 million lines / 150 MBytes, hard to work with) And, based on what the command now returns, it seems that the first two that I listed before (which are no longer present) were as a result of my (single) merge command, i.e. my merge resulted in merging : . two merges that were done by someone else in the master that I cloned into my /b filesystem, . maybe some other non-merge commits that I did not query before and now don't know > >> So I now think I see the problem with using a reset based on something >> relating to commits - >> apparently (??) there is nothing in the git log to distinguish commits >> done by my last merge versus commits prior to that. I.e. the "merge" >> does not appear to be logged as an event in its own right, only as the >> commits inside it?? > Two points: > - in git, you have commits and "pointers to commits"; and > - the commit itself IS the merge. You've lost me here. If a merge can consist of many commits, including other merges (see above), then how can one commit be a merge? Note that in my original git log --merges output that I posted in my earlier post, i.e. the one before I reset, there was *no* record of *my* merge command itself, only of the sub-merges that my merge dragged along. I think this is the crucial (to me) point - git did not record what I did, only the effects of what I did. Not saying this is wrong or right, but significant. > See below. > > >>> Also, if you just want to go back to a particular branch, you can >>> specify it to git reset, in the form of "git reset --hard >>> origin/master". This will reset (discarding any changes) YOUR branch to >>> wherever origin/master happens to be, which, from reading your message >>> seems to be where you want to go? >> Ah - that did it, thanks Tim. I had seen that one but wasn't >> sure whether it would reset me back to what I cloned or the master of >> that clone i.e. way back to the "original" origin of this build. >> >> It seems if I had not created a separate branch -- I would now be >> completely sunk? > Your branches are completely separate to the branches of other repos. Ah, ok. Good. > See below. > > >> It would be nice if there was a "git undo" which undid whatever changes >> to files+index were made by the immediately preceding git command, >> whatever it was and whatever it did. > I believe (speculation) that the reason this hasn't been done is that > there are too many things you can _DO_ in git in order to have a simple > "undo" button. Compare it to having an "undo" button in real life; what > and how much would it actually undo? There are simply too many different > situations to have something as simple as undo. > Having said that, there are ways to recover from almost every situation > in git (most of which I'm yet to learn). See below. I see it would be a large and tedious thing to code, but I do think it would be perfectly well-defined : gather all relevant information about the most recent git command that changed either files or index or pointers, and reverse its effects. In my particular case, with your insight, I can now see that it would have been quite easy to delve into the log and calculate how many carets or tildes I needed to revert back to the commit that corresponded to my initial cloned state. In a general case, I think this could easily be a complex burden for a dumb user to have to do compared with "undo what I just did". > >>> Be careful if you have made changes you want to keep, though. >> No worries there although thanks for the warning. > I've lost data a few times not thinking about what I was doing. :P > > > Alright, so I promised you a crack at an explanation. List, please feel > free to chime in and correct me where I am mistaken. > > Yes, I have used gitk and it helps a lot. Thanks again John Lumby