On Mon, Sep 19, 2011 at 11:08:31AM +0200, dieter@xxxxxxxxxxxx wrote: > this is my use case: > i create a repository and produce several commits on master. > then i go back to a certain tag and create a new branch, where i also > commit. > then i switch back to master and delete (-D) the other branch. > it should now be unreachable from within git (to prove its existence, > i remember a commit SHA1 on the dead branch). It will still be referenced by the HEAD reflog, won't it? > git checkout master > git branch -D $DEAD > git show $dead_commit > git fsck --unreachable --full --verbose This shows it reachable, because it is connected from the HEAD reflog. > git fsck --unreachable HEAD \ > $(git for-each-ref --format="%(objectname)" refs/heads) And this shows it as unreachable, because you are asking git to only look at the branch tips and HEAD (by default, it looks at all refs and reflogs). I suspect you copied this straight from the git-fsck manpage. That advice is a bit outdated, I think. It blames (in some form) all the way back to the original documentation added in c64b9b8 (2005-05-05, only a few weeks after git was born). A few weeks later, fsck learned to default to looking at all refs (1024932, 2005-05-18). And then other sane defaults like reflogs got tacked on later (reflogs came around the 1.4.x era, in 2006). > git fsck --lost-found > git prune -v $dead_commit > git prune $(git rev-parse --all) > git repack > git prune-packed > git gc --prune=now > git gc --aggressive > git show $dead_commit If you really want to make it unreachable, you should expire the reflogs, too: git reflog expire --expire=now --all # will now report unreachable git fsck --unreachable # will now actually delete objects git prune -v # gives "bad object ..." git show $dead_commit git-gc will do this for you, but of course the default expiration time is much longer (I think something like 90 days). -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html