Menu
An orphan branch is a separate branch that starts with a different root commit. So the first commit in this branch will be the root of this branch without having any history. It can be accomplished by using the Git checkout command with the ––orphan option.
On GitHub.com, you can access your project history by selecting the commit button from the code tab on your project. Locally, you can use git log . The git log command enables you to display a list of all of the commits on your current branch. By default, the git log command presents a lot of information all at once.
To pull up a list of your commits and their associated hashes, you can run the git log command. To checkout a previous commit, you will use the Git checkout command followed by the commit hash you retrieved from your Git log.
The most basic and powerful tool to do this is the git log command. By default, with no arguments, git log lists the commits made in that repository in reverse chronological order; that is, the most recent commits show up first.
Rather than leave this open I think I'll give an answer to my own question. Using git reflog --all is a good way to browse orphaned commits - and using the SHA1 hashes from that you can reconstruct history.
In my case though, the repository was corrupted so this didn't help; git fsck can help you find and sometimes fix errors in the repository itself.
With git 2.9.x/2.10 (Q3 2016), you won't have to use git reflog --all anymore, git reflog will be enough.
See commit 71abeb7 (03 Jun 2016) by SZEDER Gábor (szeder).
(Merged by Junio C Hamano -- gitster -- in commit 7949837, 06 Jul 2016)
reflog: continue walking thereflogpast root commitsIf a repository contains more than one root commit, then its HEAD reflog may contain multiple "creation events", i.e. entries whose "from" value is the null sha1.
Listing such a reflog currently stops prematurely at the first such entry, even when the reflog still contains older entries.
This can scare users into thinking that their reflog got truncated after 'git checkout --orphan'.Continue walking the reflog past such creation events based on the preceeding reflog entry's "new" value.
I typically find the git reflog output to be confusing. It's much easier for me to understand a commit graph from git log --graph --reflog. Overriding the log format to show only commit summaries also can make the graph easier to follow:
$ git config --global alias.graph \
"log --graph --all --format='%h %s%n (%an, %ar)%d' --abbrev-commit"
$ git graph --reflog
* f06abeb Add feature
| (Sue Dakota, 4 days ago) (HEAD -> master)
* f126291 Fix the build
| (Oski M. Wizard, 5 days ago) (origin/master, master)
* 3c4fb9c Move fast, break things
| (Alyssa P. Hacker, 5 days ago)
| * e3124bf fixup! More work for feature
| | (Sue Dakota, 4 days ago)
| | * 6a7a52e Lost commit
| |/ (Sue Dakota, 4 days ago)
| * 69d9438 More work for feature
| | (Sue Dakota, 2 weeks ago)
| * 8f69aba Initial work for feature
|/ (Sue Dakota, 3 weeks ago)
* d824fa9 Fix warnings from the linter
| (Theo Rhys Tudent, 4 weeks ago)
* 9f782b8 Fix test flakes
| (Tess Driven, 5 weeks ago)
From that it's clear that e3124bf and 6a7a52e are unreferenced orphans, and there's context from their ancestor commits.
One good feature of git is that it detects corruption. However, it does not include error correction to protect from corruption.
I hope that you have pushed the contents of this repository to another machine or that you have backups to recover the corrupted parts.
I do not have any experience with git on windows but have never seen this sort of behavior with git on Linux or OS X.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With