Browse orphaned commits in Git

My git repository has somehow gone wonky - I loaded up msysgit this morning and instead of the branch name being shown after the current directory, it says "((ref: re...))", 'git status' reports everything as a new file, 'git log' and 'git reflog' tell me "fatal: bad default revision 'HEAD'", and so on.

Doing 'git reflog --all' or 'gitk --all' shows me the rest of the repository is intact, but it looks like the branch I was working on has just disappeared, which explains why HEAD doesn't seem to exist/point to anything.

I know git keeps hold of all sorts of globs of information, and I'm assuming my commits have just been orphaned somehow, so is there some command that will show me those commits so I can reset HEAD to them?

EDIT: Oh dear. I discovered 'git fsck', and 'git fsck --full' reports "fatal: object 03ca4... is corrupted". What the devil can I do about that?

EDIT: Oh dear oh dear. I checked out another branch, then tried to re-create the original branch with the same name using 'git checkout -b lostbranchname', and git says "error: unable to resolve reference refs/heads/lostbranchname: No error, fatal: Failed to lock ref for update: No error". 'No error' must be a particularly nasty error. So it looks like it's still hanging around, but unable to be used and unable to be killed.

EDIT: Super duper oh dear. I've done a bunch of unpacking and repacking and replacing of things as suggested here: How to recover Git objects damaged by hard disk failure?, but now I'm getting another hash reported as corrupt, for something as innocuous as 'git status'. I think the entire thing is hosed. Git's lovely and all, but I shouldn't have to deal with this kind of thing.

54808 次浏览
小开

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.

小开
最佳答案

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 the reflog past root commits

If 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.

小开

If you wish to see only your orphaned commits, you can use the following commands (using a *nix shell):

# Save the output to a file since it might take a minute.
git fsck --unreachable > unreachable.txt
# Note unreachable.txt now includes all unreachable blobs, trees, and commits.
cat unreachable.txt | grep commit

提交答案