On Thu, Oct 19, 2006 at 07:55:18AM -0700, Linus Torvalds wrote: > On Wed, 18 Oct 2006, Junio C Hamano wrote: > > > > Linus Torvalds <torvalds@xxxxxxxx> writes: > > > > > > Actually, I've hit an impasse. > > > > > > So there's _another_ way of fixing a thin pack: it's to expand the objects > > > without a base into non-delta objects, and keeping the number of objects > > > in the pack the same. But _again_, we don't actually know which ones to > > > expand until it's too late. > > > > pack-objects.c::write_one() makes sure that we write out base > > immediately after delta if we haven't written out its base yet, > > so I suspect if you buffer one delta you should be Ok, no? > > It doesn't matter. I realized that my bogus patch to unpack-objects was > more seriously broken anyway: even the "un-deltify every single object" > was broken. And that's despite the fact that I _tested_ it, and verified > the end result by hand. > > Why? Because I tested it within one repo, by just piping the output of > git-pack-objects --stdout directly to the repacker. That seemed to be a > good way to test it without setting up anything bigger. But it turns out > that it misses one of the big problems: if you don't unpack the objects in > a way that later phases can read, none of the streaming code works at all, > and you have to buffer up _everything_ in memory just to be able to read > any previous _non_delta objects too. You are correct that it is not possible to create a pack with all objects expanded in a single pass. But that doesn't mean that a single pass conversion to a full pack is impossible. If we find a delta against a base that is not found in our repository we can keep it as a delta, the base should show up later on in the thin-pack. Whenever we find a delta against a base that we haven't seen in the received part of the thin pack, but is available from the repository we should expand it because there is a chance we may not see this base in the remainder of the thin-pack. > So my patch-series works - but it only works in a repo that already has > all the objects in question, because then it can look up the objects in > the original database. Which makes it useless. Duh. About that patch series, is there a simple way to import the series into a local repository? git-am doesn't like it, even after splitting it into separate files on the linebreaks. I guess git-mailinfo could be taught to recognise the git-log headers. Or have I missed some useful git apply trick. Jan - 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