GitX commit got all files, all other commits in branch gone

126 views
Skip to first unread message

TTop

unread,
Oct 28, 2010, 9:43:47 AM10/28/10
to GitX
I was using GitX 0.7.1 to prepare a commit. Something happened -- I
don't know what -- and suddenly my branch only had a single commit in
it that appears to contain all the files in my tree. So I went to the
command line and did this:

$ git reset --soft HEAD^
fatal: ambiguous argument 'HEAD^': unknown revision or path not in the
working tree.

When I do 'git log' in this branch, there's only one commit. Now, I
had many commits in this branch a few minutes ago. I really, really,
don't want to lose this.

What steps should I take to attempt to recover? Is there some log to
see what happened?

Nathan Kinsinger

unread,
Oct 28, 2010, 10:23:17 AM10/28/10
to gi...@googlegroups.com, TTop


Use 'git reflog' to see the history of the changes to HEAD or 'git reflog show branchname' to see changes to just that branch. Find the last SHA that seems valid and check it out.


--Nathan

http://brotherbard.com/

codex...@gmail.com

unread,
Nov 3, 2012, 1:36:06 AM11/3/12
to gi...@googlegroups.com, TTop
I've had this happen too, multiple times, doing nothing other than a normal checkin of new changes. Checkin as usual, and suddenly *bam* every previous checkin in log/history is gone. 

Has happened to me at least half a dozen times, with no warning or pattern that I can find. 

This is *insane* behavior for a revision control client!

Being able to list the reflog and view previous commit messages doesn't restore my history, or allow me to see the changes made to that history. 

I quit using GitX because of this. 

--Bill

Douglas Livingstone

unread,
Nov 3, 2012, 1:56:02 PM11/3/12
to gi...@googlegroups.com
Hi Bill,


> Being able to list the reflog and view previous commit messages doesn't restore my history, or allow me to see the changes made to that history.

One of the things which (still) excites me about git is that, actually, you can restore history using the reflog, and you can see the history leading up to each commit.

First off, git stores history as a linked list of working copy snapshots. To display the history for a commit, git log takes the latest commit, follows its parent reference to get the previous commit, then finds the next parent, etc, and prints out the commit message for each one. It can start from any commit, including ones in the reflog. Here is what it looks like:

git log master
git log master@{1}

The first line gets the log starting at the commit which the master branch currently points to, that is, the most recent commit to master.

The second line uses reflog syntax to start logging from where master most recently pointed to, that is, one step back in the reflog. master@{0} points to the current master, master@{2} points further back etc.

Next, restoring history with the reflog. First off, a branch in git is a reference to a commit, which gets updated whenever you commit to a branch. Using git reset, you can change which commit a branch points to. So, if you know the sha1 for a commit, say, from the reflog, you can change the branch to point to that. All together, if you are on the master branch (check git status) you can reset to a different commit like this:

git reset master@{1}

Finally, what is the gitx bug? Well, it sounds like you are left looking at a commit with no history, which looks like it contains a snapshot of the whole working copy. Diffs in the log diff the snapshot from one commit with the snapshot from the previous one, so if it can't find any previous commits there will be nothing to diff with, so the log will show everything as new. Since commits always reference full snapshots, that means the snapshot itself is good. The problem is finding the previous commit. GitX has probably not set the parent commit properly, so git log can't follow the history back.

HTH,
Douglas

Josh Bleecher Snyder

unread,
Nov 5, 2012, 3:26:45 PM11/5/12
to gi...@googlegroups.com
FWIW, I have experienced this too -- instead of setting the parent commit properly, a new root commit gets created. This is disorienting and disconcerting even for a fairly experienced user, and is a bummer to have to sort out. (Yes, the reflog helps, but it is still not fun to have to manually fix messed up commits.) I'd say this is a critical bug.

I don't know what the reproduction steps are, but given the diagnosis (missing parent commit), I imagine psychic debugging has a chance of success.

-josh
Reply all
Reply to author
Forward
0 new messages