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

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.
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

Reply via email to