WARNING: THIS PATCH CAN BREAK YOUR REPO, was Re: [PATCH 2/3] Only repack active packs by skipping over kept packs.

[Nicolas Pitre <nico@cam.org>]

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.