From: Junio C Hamano Date: Fri, 16 Sep 2005 17:02:49 GMT Subject: Re: git fsck messages - what to do about it? Message-ID: <7vll1xndxi.fsf@assigned-by-dhcp.cox.net> In-Reply-To: <20050916110310.90115352B7B@atlas.denx.de> Wolfgang Denk 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.