From: Duy Nguyen Date: Sun, 08 Sep 2013 06:28:47 GMT Subject: Re: [PATCH v2 1/3] index-pack: add --unpack-limit to unpack objects Message-ID: In-Reply-To: <20130908044417.GD14019@sigill.intra.peff.net> On Sun, Sep 8, 2013 at 11:44 AM, Jeff King wrote: > On Fri, Sep 06, 2013 at 07:46:01AM +0700, Nguyen Thai Ngoc Duy wrote: > >> --- >> I had something that could unpack without writing to temp pack file >> but I scraped it and chose this way because it follows closely how >> index-pack works. It's a good thing imo because .pack v4 is coming >> and I don't know how v4 may impact this unpack code path. Once things >> are settled, we can revisit and open a separate code path if it's >> still a good idea. > > From a cursory read, this seems fine. If it were done in complete > isolation, I'd say it was a slight regression, just because we are doing > more I/O for the unpack case, and it is not really saving us any code > (it is not like we can throw away unpack-objects, as I think we would > want to keep it as a last resort for getting data out of malformed or > otherwise non-indexable packs). I can see unpack-objects is more tolerable on corrupt/incomplete packs. If index-pack finds something wrong, it aborts the whole process. I think we can make index-pack stop at the first bad object, adjust nr_objects, and try to recover as much as possible out of the good part. Any other reasons to keep unpack-objects (because I still want to kill it)? > But I can also see it making pack v4 handling easier. So it would make > sense to me to put it at the start of a series adding pack v4 indexing. > By the end of the series you would be able to see the benefits of the > reduced code complexity. Until then, it is a "probably this will help > later" change. Agreed. -- Duy