Listing and deleting Git commits that are under no branch (dangling?)

user_171428 0
Viewed 91363

I've got a Git repository with plenty of commits that are under no particular branch, I can git show them, but when I try to list branches that contain them, it reports back nothing.

I thought this is the dangling commits/tree issue (as a result of -D branch), so I pruned the repo, but I still see the same behavior after that:

$ git fetch origin

$ git fsck --unreachable
$ git fsck

No output, nothing dangling (right?). But the commit exists

$ git show 793db7f272ba4bbdd1e32f14410a52a412667042
commit 793db7f272ba4bbdd1e32f14410a52a412667042
Author: ...

and it is not reachable through any branch as

$ git branch --contains 793db7f272ba4bbdd1e32f14410a52a412667042

gives no output.

What exactly is the state of that commit? How can I list all commits in a similar state? How can I delete commits like those?

git-dangling branch git
9 Answers

To remove all dangling commits (including those still reachable from stashes and other reflogs) do this:

git reflog expire --expire-unreachable=now --all
git gc --prune=now

But be certain that this is what you want. I recommend you read the man pages but here is the gist:

git gc removes unreachable objects (commits, trees, blobs (files)). An object is unreachable if it isn't part of the history of some branch. Actually it is a bit more complicated:

Stashes are implemented using the reflog (i.e not not branches or tags). That means that they are subject to garbage collection.

git gc does some other things but they are not relevant here and not dangerous.

Unreachable objects that are younger than two weeks are not removed so we use --prune=now which means "remove unreachable objects that were created before now".

Objects can also be reached through the reflog. While branches record the history of some project, reflogs record the history of these branches. If you amend, reset etc. commits are removed from the branch history but git keeps them around in case you realize that you made a mistake. Reflogs are a convenient way to find out what destructive (and other) operations were performed on a branch (or HEAD), making it easier to undo a destructive operation.

So we also have to remove the reflogs to actually remove everything not reachable from a branch. We do so by expiring --all reflogs. Again git keeps a bit of the reflogs to protect users so we again have to tell it not to do so: --expire-unreachable=now.

Since I mainly use the reflog to recover from destructive operations I usually use --expire=now instead, which zaps the reflogs completely.

tarsius_510190

I accidentally hit the same situation and found my stashes contain reference to the unreachable commit, and thus the presumed unreachable commit was reachable from stashes.

These were what I did to make it truly unreachable.

git stash clear
git reflog expire --expire-unreachable=now --all
git fsck --unreachable
git gc --prune=now
user_21175310

If the stash is truly a stash that "doesn't exist" and not a tag,
git fsck --full
may help. It worked for me when no other solution did.

(Git: Remove broken stash describes my problem more accurately than this thread)

user_10522840

I know this is not a good solution but I did a filter-branch and ended up with duplicate, unreachable commits which didn't belong to any branch but couldn't remove them automatically, I tried every single solution posted here, absolutely nothing worked. So I pushed to a remote repository (github), deleted my local repository and then pulled again and got rid of all those unreachable commits

user_12750650
Related