Re: [PATCH 2/8] pack-objects: produce a stable pack when --skip is given
From: Junio C Hamano <hidden>
Date: 2016-06-15 23:08:07
Nguyễn Thái Ngọc Duy [off-list ref] writes:
quoted hunk
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c index 417c830..c58a9cb 100644 --- a/builtin/pack-objects.c +++ b/builtin/pack-objects.c@@ -2709,6 +2709,11 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix) if (get_oid_hex(skip_hash_hex, &skip_hash)) die(_("%s is not SHA-1"), skip_hash_hex); } + + /* + * Parallel delta search can't produce stable packs. + */ + delta_search_threads = 1; } argv_array_push(&rp, "pack-objects");
A multi-threaded packing is _one_ source of regenerating the same pack for the same set of objects, but we shouldn't be tying our hands by promising it will forever be the _only_ source of it by doing things like this. We may want to dynamically tweak the packing behaviour depending on the load of the minute and such for example. This is an indication that the approach this series takes is taking us in a wrong direction. I think a more sensible approach for "resuming" is to attack cloning first. Take a reasonable baseline snapshot periodically (depending on the activity level of the project, the interval may span between 12 hours to 2 weeks and you would want to make it configurable) to create a bundle, teach "clone" to check the bundle first and perform a resumable and bulk transfer for the stable part of the history (e.g. up to the latest tag or a branch that does not rewind, the set of refs to use as the stable anchors you would want to make configurable), and then fill the gap between that baseline snapshot and up-to-date state by doing another round of "git fetch" and then you'd have solved the most serious problem already.