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

[John Lumby <johnlumby@hotmail.com>]

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

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