views:

85

answers:

2

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 case after that:

$ git fetch origin

$ git fsck --unreachable
$ git fsck

No output, nothing dangling (right?)

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

But

$ git branch --contains 793db7f272ba4bbdd1e32f14410a52a412667042

Gives no output

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

+1  A: 

git gc --prune=<date> defaults to prune objects older than two weeks ago. You could set a more recent date. But, git commands that create loose objects generally will run git gc --auto (which prunes loose objects if their number exceeds the value of configuration variable gc.auto).

Are you sure that you want to delete these commits? gc.auto's default setting will ensure that the loose objects do not take up an unreasonable amount of memory, and storing loose objects for some amount of time is generally a good idea. That way, if you realize tomorrow that your deleted branch contained a commit you needed, you can recover it.

dublev
+2  A: 

No output, nothing dangling (right?)

Note that commits referred to from your reflog are considered reachable.

What exactly is the state of that commit? How can I list all commits with similar state

Pass --no-reflogs to convince git fsck to show them to you.

How can I delete commits like those?

Once your reflog entries are expired, those objects will then also be cleaned up by git gc.

Expiry is regulated by the gc.pruneexpire, gc.reflogexpire, and gc.reflogexpireunreachable settings. Cf. git help config.

The defaults are all quite reasonable.

Aristotle Pagaltzis