On Tue, Mar 26, 2013 at 3:26 AM, Jeff King <p...@peff.net> wrote: > The slowdown is really quite terrible if you try "git clone --bare > linux-2.6.git". Even with this, the local-clone case already misses blob > corruption. So it probably makes sense to restrict it to just the > non-local clone case, which already has to do more work. > > Even still, it adds a non-trivial amount of work (linux-2.6 takes > something like a minute to check). I don't like the idea of declaring > "git clone" non-safe unless you turn on transfer.fsckObjects, though. It > should have the same safety as "git fetch".
Maybe we could do it in index-pack to save some (wall) time. I haven't tried but I think it might work. The problem is to make sure the pack contains objects for all sha1 references in the pack. By that description, we don't need to do standard DAG traversal. We could extract sha-1 references in index-pack as we uncompress objects and put all "want" sha-1 in a hash table. At the end of index-pack, we check if any sha-1 in the hash table still points to non-existing object. This way, at least we don't need to uncompress all objects again in rev-list. We could parse+hash in both phases in index-pack. The first phase (parse_pack_objects) is usually I/O bound, we could hide some cost there. The second phase is multithreaded, all the better. -- Duy -- 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
