Re: git -- how to revert build to as-originally-cloned?

From: John Lumby <johnlumby@hotmail.com>
Date: May 20, 2011, 14:15 UTC
Message-ID: <4DD67798.4050503@hotmail.com>
In-Reply-To: <SNT124-W51D709B129B6A940ED17F2C4710@phx.gbl>

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:

Show 18 quoted lines

>
>>> 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 <davem@davemloft.net>
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

Show 10 quoted lines

>
>> 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.

Show 15 quoted lines

> 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.

Show 13 quoted lines

> 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".

Show 10 quoted lines

>
>>> 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