Branches - Git Recipes - page 179

Figure 5-12 . The current branch in the repository can be shown by an asterisk prepended to the master or by includ-
ing a .git/HEAD reference
When the repository is in the state shown in Figure 5-12 then the command $ ls
returns only three files m1.txt , m2.txt , m3.txt —the files x1.txt , x2.txt ,
and x3.txt are not available.
How to retrieve dangling revisions? First, analyze the output of the $ git
checkout master command. It contains the detailed information that your three
revisions x1 , x2 , and x3 needs to be retrieved back with the command similar to
(surely, your SHA-1 will be different):
$ git branch new_branch_name 01f3af0
The above command creates a branch named new_branch_name that will point
to the commit x3 (its SHA-1 name is written as 01f3af0 ). If the above information is
not available for some reason you can always use the reflog to restore lost commits.
Right now you can return to the x3 commit with $ git checkout HEAD@{1} .
How can you finally loose dangling revisions? We have already practiced it in Re-
cipe 3-12. If you clear the reflog and prune the database with $ git prune , then all
dangling revisions will be ultimately lost. Let's do it. Clear the reflog with $ git
reflog expire --all --expire=now . It can be done with the simple $ rm
.git/logs/* command. Now, you can check which objects would be lost with
either of two commands:
$ git prune --dry-run
$ git fsck --unreachable
The output should contain three commits ( x1 , x2 , x3 ), three files 4 ( x1.txt ,
x2.txt , x3.txt ) and three trees (one tree for every commit).
Hint A tree is a snapshot of given directory. Every commit contains a tree for the
main folder of the working directory.
Now, if you run $ git prune all dangling revisions will be removed from the
database. However, it won't be possible to get them back again.