On Sun, 29 Oct 2006, Shawn Pearce wrote: > During `git repack -a -d` only repack objects which are loose or > which reside in an active (a non-kept) pack. This allows the user > to keep large packs as-is without continuous repacking and can be > very helpful on large repositories. Something is really broken here. Here's how to destroy your GIT's git repository. WARNING: MAKE A COPY BEFORE TRYING THIS! I'm serious. First, let's make a single pack just to make things simpler and reproducible: $ git-repack -a -f -d $ git-prune $ git-fsck-objects --full So far everything should be fine. It's still time to make a backup copy of your .git directory if you've not done so. Now let's create a second pack containing a subset of the existing one. $ git-rev-list --objects v1.4.3..v1.4.3.3 | \ git-pack-objects --stdout | \ git-index-pack --stdin -v --keep $ git-fsck-objects --full At this point the repository is still fine, but the --keep to git-index-pack above will have created a file called .git/objects/pack/pack-aceb4c6394c586abaf65d76dd6cf088f50a5b806.keep and that is the source of all the trouble to come. You still can remove that file if you don't have a backup yet. If you still want to give it the coup de grace, just do: $ git-repack -a -d And now you've just lost a large amount of objects. To see the extent of the dammage, just do: $ git-fsck-objects So... what is the --unpacked=<pack>.pack switch supposed to mean? It is not documented anywhere and it certainly doesn't produce the expected result with a repack. Nicolas - 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