Am 12.03.2012 03:03, schrieb Joey Hess: > pristine-tar commit writes, to the pristine-tar branch of your > repository, a file named `$origtarball.id`. This file contains the > git sha1 of the branch you told it to commit, which is the data > that pristine-tar checkout relies on to put the tarball back > together. > > By filter-branching your repo, you have changed the sha1 of all > the commits in the branches. By running git gc, you nuked the refs > that pristine-tar relied on.
It was not clear to me how pristine-tar works. Perhaps you should add a note to the manpage pointing to the dangers of using filter-tree with pristine-tar. > pristine-tar could store the sha1 of the tree, rather than the sha1 > of the commit. That would have avoided your problem, since your > filter-branch did not change any trees. It does not avoid the > problem when doing a filter-branch generally, since it can and > often is used to change trees too. Would it be an option to use tags instead of commit ids? As i read git can tag any object, so you can tag the commit (or tree) after import and use that. filter-tree at least warns abount not changing tags if someone changes the commit. > Of course, making this change would do nothing to existing > repositories that contain tree sha1's in the id files. You're free > to check out the pristine-tar branch of your repo and fix up the > `$origtarball.id` to contain the new refs manually.. Also worth an addition to the man page? "how to recover from filter- tree"? -- MfG, Christian Welzel GPG-Key: pub 4096R/5117E119 2011-09-19 Fingerprint: 3688 337C 0D3E 3725 94EC E401 8D52 CDE9 5117 E119 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
