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. Now want go to C1 ; Ho do I Determine C1 using git command ?
Thx/ Mahesh Bangalore India.
Shawn O. PearceRe: recovering orphaned commit
Mahesh Vaidya <forvaidya@gmail.com> wrote:
> 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. > Now want go to C1 ; Ho do I Determine C1 using git command ?
Use `git reflog show` or `git log -g` to view the reflog entries for HEAD. It will show you the different states HEAD had, so you want to find the state before you reset to C2, that would be C1.
-- Shawn.
Ramkumar RamachandraRe: recovering orphaned commit
Hi Mahesh,
Mahesh Vaidya writes:
> 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. > Now want go to C1 ; Ho do I Determine C1 using git command ?
Use git-reflog (1) perhaps?
-- Ram
Jonathan NiederRe: recovering orphaned commit
Hi Mahesh,
Mahesh Vaidya wrote:
> 2899684ed173063354b7fe4f5ec7216e7d953e2c <-- HEAD ( say C1) > 1ef67de1a0d6e97470a8c827d2989317600532ff ( say C2) > > To see file at C2 ; I have done git reset --hard C2
For the future, ‘git checkout C2’ might work better for this task. Unlike ‘git reset’, it does not change where the current branch head points, so when you’re done exploring you can get back to where you were with ‘git checkout topic’ (where topic is the name of the branch --- e.g., master).
> Now want go to C1 ; Ho do I Determine C1 using git command ?
git log -g HEAD
Hope that helps, Jonathan
Wincent ColaiutaRe: recovering orphaned commit
El 29/06/2010, a las 17:09, Mahesh Vaidya escribió:
> 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