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

Wolfgang Denk [off-list ref] writes:

Ummm.... I hesitate to  do  this  before  understanding  where  these
messages come from and what sort of data is affected.

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.