On Sun, Sep 8, 2013 at 11:44 AM, Jeff King <p...@peff.net> 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html