Re: git fsck messages - what to do about it?

Wolfgang Denk <wd@denx.de> writes:

Does git-fsck-cache without --unreachable report dangling commits? If so I would do something like this (this is my 'git-lost-found' script):

        #!/bin/sh

        . git-sh-setup-script || die "Not a git archive."

        laf="$GIT_DIR/refs/lost-found"
        mkdir -p "$laf" || exit

        git fsck-cache |
        while read dangling type sha1
        do
                case "$dangling" in
                dangling)
                        echo "$sha1" >"$laf/$sha1"
                        case "$type" in
                        commit)
                                git-show-branch "$sha1" ;;
                        esac
                        ;;
                esac
        done

and run 'gitk --all' to see what these dangling commits are, and where in your commit ancestry mesh they fit in.

After you understand what they are, do not forget to "rm -f $GIT_DIR/refs/lost-found/*"; you made them reachable just to make inspecting them easier, but you probably do not want them.

I can sort of understand dangling blobs can come from manually resolved merges, but I do not think that would create dangling commits.

Have you rewound and rebased your history? 'git reset --hard' obviously throws the tip of the current branch away and 'git rebase' does it in order to recreate an alternate history. If that is the case, and if you are satisfied with the history your repository currently have, then obviously these can be safely pruned.

Another possibility is what Pasky suggested -- do you have a symlink .git/objects in another repository that points at the .git/objects directory of this repository? These dangling things may be objects the other repository needs. If that is the case you obviously cannot prune them -- you would corrupt the other repository.