Christian Couder <christian.couder@xxxxxxxxx> writes: > We have the following order: > > - finish_pack_objects_cmd() is called for the first pack-objects > process. It populates the 'names' string_list with the temporary name > of the packfile it generated (which doesn't contain the filtered out > objects) and calls finish_command() to finish the first pack-objects > process. So as far as I understand nothing can be written anymore to > the packfile when finish_pack_objects_cmd() returns. > > - write_filtered_pack() is called. It starts the second pack-objects > process and passes it the temporary name of the packfile that was just > written, taking it from the 'names' string_list. It then calls > finish_pack_objects_cmd() for the second process which populates the > 'names' string_list with the temporary name of the packfile created by > the second process and finishes the second process. So nothing can > then be written in the second packfile anymore. > > - close_object_store() is called which renames the packfiles from > the 'names' string_list giving them their final name. "which renames" -> "and then we enter a loop to rename" and close_object_store() itself and its callees do not do much, but yes, you are right. As finish_pack_objects_cmd() is synchronous, there cannot be such race as a feared (if we were feeding the pack objects process that collects the objects that would have filtered out with the final packfile paths, and if we were only renaming them to the final paths after that close_object_store() call, then the process would want to see the final names that are not there yet, but that's not a race but a bug that would reliably trigger). > So the final names are given only once both processes are finished and > both packfiles have been fully written. Thanks for walking through the codepaths involved. We are good then.
