Hi, On Mon, 23 Oct 2023, Junio C Hamano wrote: > Taylor Blau <me@xxxxxxxxxxxx> writes: > > > But I think that this approach ended up being less heavy-weight than I > > had originally imagined, so I think that this version is a worthwhile > > improvement over v4. > > ;-). > > This version is a good place to stop, a bit short of going full OO. > Nicely done. I wonder whether a more generic approach would be more desirable, an approach that would work for `git replay`, too, for example (where streaming objects does not work because they need to be made available immediately because subsequent `merge_incore_nonrecursive()` might expect the created objects to be present)? 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. This would probably need to be implemented as a new `tmp_objdir_pack_and_migrate()` function that basically spawns `pack-objects` and feeds it the list of generated objects, writing directly into the non-temporary object directory, then discarding the `tmp_objdir`. This approach would not only more easily extend to other commands, but it would also be less intrusive (a `tmp_objdir_*()` call to begin the transaction before the objects are written, another one to commit the transaction after the objects are written), and it would potentially allow for more efficient packs to be generated. Ciao, Johannes
