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@xxxxxxxxxxxxx>
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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html