grafts+repack+prune = history at danger

Isn't there a major hole in the logic how repack works when grafts are in effect?

I did this (details follow):

1. specify grafts
2. repack
3. prune
4. clone

Result: Broken history in the clone; info/grafts was not copied.
This is with git version 1.5.0.rc2.g18af.

1. I imported a cvs repository into git and "fixed" the history using
grafts. In particular:

      o--B--X   <== this commit is should be skipped
          \  \
graft =>   ---A--o

I specified in .git/info/grafts that the parent of A should be B. Of course, commit A has still recorded X as its parent.

2. Then I repacked the repo. But this did not erase all objects:

$ git repack -a -d $ git count-objects -v count: 5 size: 28 in-pack: 3392 packs: 1 prune-packable: 0 garbage: 0 $ git fsck-objects dangling commit bb828bfbd213a97817a95506bab4eeaa70538e2e

This commit bb828... is X.

3. Now git prune happily removes the 5 objects.

4. 'git clone First Second' clones the repository without problems.

But now in the clone the history is kaputt. Because commit X is not in the cloned pack. Nor is there any info/grafts file. The original history is still OK as long as the info/grafts file is present; but if it is removed, the original repo is also damaged.

IMHO, this is a very serious issue. I think that repack should not walk the grafted history. Alternatively, the info/grafts file must be copied by the clone and respected by fsck-objects.

-- Hannes