From: Jon Seymour Date: Sat, 23 Jul 2011 08:39:17 GMT Subject: RFC: Should git gc/repack respect .git/refs/replace? Message-ID: I recently damaged a USB drive containing an archive of a finished project. I am able to paper over a week of missing history by using the git replace mechanism, so that git rev-list now works as expected. When I run git gc or git repack, I get the following: error: Could not read 023a1d5d3977420ba041cb556c0eee17c326aeb6 fatal: Failed to traverse parents of commit 44d578ea81f7a90989e2ee3c676f50e3aff7071f where 0bbded9a764d9f4c8dc27b778f70d044df65f65f is one of the missing commits I replaced with: git replace 023a1d5d3977420ba041cb556c0eee17c326aeb6 238d237db9137b4eaf96f1d554bf2668729b9b93 Is this expected behaviour? I had assumed that git repack would respect the topology implied by git replace. Some other differences: git cat-file commit 023a1d5d3977420ba041cb556c0eee17c326aeb6 produces the expected output (that is the same as git cat-file commit 238d237db9137b4eaf96f1d554bf2668729b9b93), but git cat-file commit -t 023a1d5d3977420ba041cb556c0eee17c326aeb6 fails with: error: unable to find 023a1d5d3977420ba041cb556c0eee17c326aeb6 fatal: git cat-file 023a1d5d3977420ba041cb556c0eee17c326aeb6: bad file In my view, it seems reasonable that git repack should tolerate repos that have replace references in them otherwise you can never recover unused space. Thoughts? jon.