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