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.
--
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