Re: recovering orphaned commit

From: Wincent Colaiuta <win@wincent.com>
Date: Jun 29, 2010, 15:29 UTC
Message-ID: <A91ACF1D-6773-4EDA-98F5-DD6F993577CB@wincent.com>
In-Reply-To: <AANLkTiks6yPfdTACQwZlqv8PPPEg3RYGMx1Q1PjT0nRu@mail.gmail.com>

El 29/06/2010, a las 17:09, Mahesh Vaidya escribió:

Show 8 quoted lines

> I have a situation like this; 2 commits.
> 
> Example -
> 
> 2899684ed173063354b7fe4f5ec7216e7d953e2c	 <-- HEAD  ( say C1)
> 1ef67de1a0d6e97470a8c827d2989317600532ff                    ( say C2)
> 
> To see file at C2 ; I have done git reset --hard C2; I could see the file.

"git reset --hard" isn't really intended as a tool for inspecting files in other revisions. Didn't the "--hard" switch suggest that you were about to do something potentially dangerous? (The danger here, as noted in the manpage, is that you will lose any uncommitted changes that might be in the working tree.)

"git show REV:FILE" could be used to inspect the state of FILE as it was in commit REV.

If you just want to snoop around the tree you could also just checkout the revision ("git checkout REV") and when you're done go back to your old HEAD ("git checkout master" or whatever branch you were on).

You could also try using "gitk" for general point-and-click snooping around over revisions and trees.

> Now want go to C1 ; Ho do I Determine C1  using git command ?

Well, even though you overwrote the old value of HEAD, it is still in the reflog, which you can inspect with "git reflog".

And if you just want to actually put the HEAD back the way it was before, you could use "git reset" again (ie. "git reset C1"). As the man page says, the "--hard" switch here will not only update the HEAD, but also update the contents of the working tree to match it.

Cheers, Wincent