Re: [PATCH v5 0/5] merge-ort: implement support for packing objects together

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 6, 2023, 23:19 UTC
Message-ID: <xmqqr0l2cvx5.fsf@gitster.g>
In-Reply-To: <0ac32374-7d52-8f0c-8583-110de678291e@gmx.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 5 quoted lines

> What I have in mind is more along Elijah's suggestion at the Contributor
> Summit to use the `tmp_objdir*()` machinery. But instead of discarding the
> temporary object database, the contained objects would be repacked and the
> `.pack`, (maybe `.rev`) and the `.idx` file would then be moved (in that
> order) before discarding the temporary object database.

That may be more involved but does indeed sound like an approach more generally applicable. Back when the bulk-checkin machinery was invented, I envisioned that we would be adding annotations to various codepaths so that object creation machinery can say "now we are plugged, in anticipation for creating many objects at once" and "now the flood of new object creation is done, time to wrap up" for that kind of optimization.

The callsites to {begin,end}_odb_transaction() functions haven't grown beyond the original "add" and "update-index" (because the user can add the entire working tree worth of files to the object database), "unpack-objects" (because a fetch can bring in many objects), and "cache-tree" (because a tree creation can cascade up to create many objects), but I agree "merge" and "replay" are prime candidates to benefit from the optimization of the same kind (so is "fast-import"). They are about creating many objects at once, and give us an opportunity for such an optimization.