{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":177595211,"defaultBranch":"private","name":"git","ownerLogin":"ttaylorr","currentUserCanPush":false,"isFork":true,"isEmpty":false,"createdAt":"2019-03-25T13:46:59.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/443245?v=4","public":true,"private":false,"isOrgOwned":false},"refInfo":{"name":"","listCacheKey":"v0:1725651998.0","currentOid":""},"activityList":{"items":[{"before":"2b088183aa32959e589010a2cc83085a2b75eb8e","after":"4018261366fe2de2def2ec6093ccfb51ef768a7b","ref":"refs/heads/tb/fast-sha1","pushedAt":"2024-09-06T19:46:38.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"ttaylorr","name":"Taylor Blau","path":"/ttaylorr","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/443245?s=80&v=4"},"commit":{"message":"csum-file.c: use fast SHA-1 implementation when available\n\nUpdate hashwrite() and friends to use the fast_-variants of hashing\nfunctions, calling for e.g., \"the_hash_algo->fast_update_fn()\" instead\nof \"the_hash_algo->update_fn()\".\n\nThese callers only use the_hash_algo to produce a checksum, which we\ndepend on for data integrity, but not for cryptographic purposes, so\nthese callers are safe to use the fast (and potentially non-collision\ndetecting) SHA-1 implementation.\n\nTo time this, I took a freshly packed copy of linux.git, and ran the\nfollowing with and without the OPENSSL_SHA1_FAST=1 build-knob. Both\nversions were compiled with -O3:\n\n    $ git for-each-ref --format='%(objectname)' refs/heads refs/tags >in\n    $ valgrind --tool=callgrind ~/src/git/git-pack-objects \\\n        --revs --stdout --all-progress --use-bitmap-index <in >/dev/null\n\nWithout OPENSSL_SHA1_FAST=1 (that is, using the collision-detecting\nSHA-1 implementation for both cryptographic and non-cryptographic\npurposes), we spend a significant amount of our instruction count in\nhashwrite():\n\n    $ callgrind_annotate --inclusive=yes | grep hashwrite | head -n1\n    159,998,868,413 (79.42%)  /home/ttaylorr/src/git/csum-file.c:hashwrite [/home/ttaylorr/src/git/git-pack-objects]\n\n, and the resulting \"clone\" takes 19.219 seconds of wall clock time,\n18.94 seconds of user time and 0.28 seconds of system time.\n\nCompiling with OPENSSL_SHA1_FAST=1, we spend ~60% fewer instructions in\nhashwrite():\n\n    $ callgrind_annotate --inclusive=yes | grep hashwrite | head -n1\n     59,164,001,176 (58.79%)  /home/ttaylorr/src/git/csum-file.c:hashwrite [/home/ttaylorr/src/git/git-pack-objects]\n\n, and generate the resulting \"clone\" much faster, in only 11.597 seconds\nof wall time, 11.37 seconds of user time, and 0.23 seconds of system\ntime, for a ~40% speed-up.\n\nSigned-off-by: Taylor Blau <me@ttaylorr.com>","shortMessageHtmlLink":"csum-file.c: use fast SHA-1 implementation when available"}},{"before":"8a8b9fbf7c6c7ed37db12b5c363796eaaed8f18f","after":"2b088183aa32959e589010a2cc83085a2b75eb8e","ref":"refs/heads/tb/fast-sha1","pushedAt":"2024-09-06T15:49:47.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"ttaylorr","name":"Taylor Blau","path":"/ttaylorr","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/443245?s=80&v=4"},"commit":{"message":"csum-file.c: use fast SHA-1 implementation when available\n\nUpdate hashwrite() and friends to use the fast_-variants of hashing\nfunctions, calling for e.g., \"the_hash_algo->fast_update_fn()\" instead\nof \"the_hash_algo->update_fn()\".\n\nThese callers only use the_hash_algo to produce a checksum, which we\ndepend on for data integrity, but not for cryptographic purposes, so\nthese callers are safe to use the fast (and potentially non-collision\ndetecting) SHA-1 implementation.\n\nTo time this, I took a freshly packed copy of linux.git, and ran the\nfollowing with and without the OPENSSL_SHA1_FAST=1 build-knob. Both\nversions were compiled with -O3:\n\n    $ git for-each-ref --format='%(objectname)' refs/heads refs/tags >in\n    $ valgrind --tool=callgrind ~/src/git/git-pack-objects \\\n        --revs --stdout --all-progress --use-bitmap-index <in >/dev/null\n\nWithout OPENSSL_SHA1_FAST=1 (that is, using the collision-detecting\nSHA-1 implementation for both cryptographic and non-cryptographic\npurposes), we spend a significant amount of our instruction count in\nhashwrite():\n\n    $ callgrind_annotate --inclusive=yes | grep hashwrite | head -n1\n    159,998,868,413 (79.42%)  /home/ttaylorr/src/git/csum-file.c:hashwrite [/home/ttaylorr/src/git/git-pack-objects]\n\n, and the resulting \"clone\" takes 19.219 seconds of wall clock time,\n18.94 seconds of user time and 0.28 seconds of system time.\n\nCompiling with OPENSSL_SHA1_FAST=1, we spend ~60% fewer instructions in\nhashwrite():\n\n    $ callgrind_annotate --inclusive=yes | grep hashwrite | head -n1\n     59,164,001,176 (58.79%)  /home/ttaylorr/src/git/csum-file.c:hashwrite [/home/ttaylorr/src/git/git-pack-objects]\n\n, and generate the resulting \"clone\" much faster, in only 11.597 seconds\nof wall time, 11.37 seconds of user time, and 0.23 seconds of system\ntime, for a ~40% speed-up.\n\nSigned-off-by: Taylor Blau <me@ttaylorr.com>","shortMessageHtmlLink":"csum-file.c: use fast SHA-1 implementation when available"}},{"before":"04f5a52757cd92347271e24f7cbdfe15dafce3b7","after":"159f2d50e75c17382c9f4eb7cbda671a6fa612d1","ref":"refs/heads/master","pushedAt":"2024-09-06T15:48:53.000Z","pushType":"push","commitsCount":494,"pusher":{"login":"ttaylorr","name":"Taylor Blau","path":"/ttaylorr","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/443245?s=80&v=4"},"commit":{"message":"Sync with 'maint'","shortMessageHtmlLink":"Sync with 'maint'"}},{"before":"2288a56a11cc58e33393db38bb5c6e9b8a7bbea5","after":"8a8b9fbf7c6c7ed37db12b5c363796eaaed8f18f","ref":"refs/heads/tb/fast-sha1","pushedAt":"2024-09-06T15:48:44.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"ttaylorr","name":"Taylor Blau","path":"/ttaylorr","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/443245?s=80&v=4"},"commit":{"message":"csum-file.c: use fast SHA-1 implementation when available\n\nUpdate hashwrite() and friends to use the fast_-variants of hashing\nfunctions, calling for e.g., \"the_hash_algo->fast_update_fn()\" instead\nof \"the_hash_algo->update_fn()\".\n\nThese callers only use the_hash_algo to produce a checksum, which we\ndepend on for data integrity, but not for cryptographic purposes, so\nthese callers are safe to use the fast (and potentially non-collision\ndetecting) SHA-1 implementation.\n\nTo time this, I took a freshly packed copy of linux.git, and ran the\nfollowing with and without the OPENSSL_SHA1_FAST=1 build-knob. Both\nversions were compiled with -O3:\n\n    $ git for-each-ref --format='%(objectname)' refs/heads refs/tags >in\n    $ valgrind --tool=callgrind ~/src/git/git-pack-objects \\\n        --revs --stdout --all-progress --use-bitmap-index <in >/dev/null\n\nWithout OPENSSL_SHA1_FAST=1 (that is, using the collision-detecting\nSHA-1 implementation for both cryptographic and non-cryptographic\npurposes), we spend a significant amount of our instruction count in\nhashwrite():\n\n    $ callgrind_annotate --inclusive=yes | grep hashwrite | head -n1\n    159,998,868,413 (79.42%)  /home/ttaylorr/src/git/csum-file.c:hashwrite [/home/ttaylorr/src/git/git-pack-objects]\n\n, and the resulting \"clone\" takes 19.219 seconds of wall clock time,\n18.94 seconds of user time and 0.28 seconds of system time.\n\nCompiling with OPENSSL_SHA1_FAST=1, we spend ~60% fewer instructions in\nhashwrite():\n\n    $ callgrind_annotate --inclusive=yes | grep hashwrite | head -n1\n     59,164,001,176 (58.79%)  /home/ttaylorr/src/git/csum-file.c:hashwrite [/home/ttaylorr/src/git/git-pack-objects]\n\n, and generate the resulting \"clone\" much faster, in only 11.597 seconds\nof wall time, 11.37 seconds of user time, and 0.23 seconds of system\ntime, for a ~40% speed-up.\n\nSigned-off-by: Taylor Blau <me@ttaylorr.com>","shortMessageHtmlLink":"csum-file.c: use fast SHA-1 implementation when available"}},{"before":"0f6eaaf8b49b7ad7cbd8cb8a4a75c9a031534b11","after":"2288a56a11cc58e33393db38bb5c6e9b8a7bbea5","ref":"refs/heads/tb/fast-sha1","pushedAt":"2024-09-05T22:42:48.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"ttaylorr","name":"Taylor Blau","path":"/ttaylorr","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/443245?s=80&v=4"},"commit":{"message":"csum-file.c: use fast SHA-1 implementation when available\n\nUpdate hashwrite() and friends to use the fast_-variants of hashing\nfunctions, calling for e.g., \"the_hash_algo->fast_update_fn()\" instead\nof \"the_hash_algo->update_fn()\".\n\nThese callers only use the_hash_algo to produce a checksum, which we\ndepend on for data integrity, but not for cryptographic purposes, so\nthese callers are safe to use the fast (and potentially non-collision\ndetecting) SHA-1 implementation.\n\nTo time this, I took a freshly packed copy of linux.git, and ran the\nfollowing with and without the OPENSSL_SHA1_FAST=1 build-knob. Both\nversions were compiled with -O3:\n\n    $ git for-each-ref --format='%(objectname)' refs/heads refs/tags >in\n    $ valgrind --tool=callgrind ~/src/git/git-pack-objects \\\n        --revs --stdout --all-progress --use-bitmap-index <in >/dev/null\n\nWithout OPENSSL_SHA1_FAST=1 (that is, using the collision-detecting\nSHA-1 implementation for both cryptographic and non-cryptographic\npurposes), we spend a significant amount of our instruction count in\nhashwrite():\n\n    $ callgrind_annotate --inclusive=yes | grep hashwrite | head -n1\n    159,998,868,413 (79.42%)  /home/ttaylorr/src/git/csum-file.c:hashwrite [/home/ttaylorr/src/git/git-pack-objects]\n\n, and the resulting \"clone\" takes 19.219 seconds of wall clock time,\n18.94 seconds of user time and 0.28 seconds of system time.\n\nCompiling with OPENSSL_SHA1_FAST=1, we spend ~60% fewer instructions in\nhashwrite():\n\n    $ callgrind_annotate --inclusive=yes | grep hashwrite | head -n1\n     59,164,001,176 (58.79%)  /home/ttaylorr/src/git/csum-file.c:hashwrite [/home/ttaylorr/src/git/git-pack-objects]\n\n, and generate the resulting \"clone\" much faster, in only 11.597 seconds\nof wall time, 11.37 seconds of user time, and 0.23 seconds of system\ntime, for a ~40% speed-up.\n\nSigned-off-by: Taylor Blau <me@ttaylorr.com>","shortMessageHtmlLink":"csum-file.c: use fast SHA-1 implementation when available"}},{"before":"311fcc95960ed46d2ff01a61e554e0a2efbbe931","after":"0f6eaaf8b49b7ad7cbd8cb8a4a75c9a031534b11","ref":"refs/heads/tb/fast-sha1","pushedAt":"2024-09-05T21:46:05.000Z","pushType":"push","commitsCount":4,"pusher":{"login":"ttaylorr","name":"Taylor Blau","path":"/ttaylorr","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/443245?s=80&v=4"},"commit":{"message":"WIP\n\nSigned-off-by: Taylor Blau <me@ttaylorr.com>","shortMessageHtmlLink":"WIP"}},{"before":"e8f5cbd280cc07f68014bd4024d55a740374b349","after":"311fcc95960ed46d2ff01a61e554e0a2efbbe931","ref":"refs/heads/tb/fast-sha1","pushedAt":"2024-09-05T15:12:24.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"ttaylorr","name":"Taylor Blau","path":"/ttaylorr","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/443245?s=80&v=4"},"commit":{"message":"csum-file.c: use fast SHA-1 implementation when available\n\nUpdate hashwrite() and friends to use the fast_-variants of hashing\nfunctions, calling for e.g., \"the_hash_algo->fast_update_fn()\" instead\nof \"the_hash_algo->update_fn()\".\n\nThese callers only use the_hash_algo to produce a checksum, which we\ndepend on for data integrity, but not for cryptographic purposes, so\nthese callers are safe to use the fast (and potentially non-collision\ndetecting) SHA-1 implementation.\n\nTo time this, I took a freshly packed copy of linux.git, and ran the\nfollowing with and without the OPENSSL_SHA1_FAST=1 build-knob. Both\nversions were compiled with -O3:\n\n    $ git for-each-ref --format='%(objectname)' refs/heads refs/tags >in\n    $ valgrind --tool=callgrind ~/src/git/git-pack-objects \\\n        --revs --stdout --all-progress --use-bitmap-index <in >/dev/null\n\nWithout OPENSSL_SHA1_FAST=1 (that is, using the collision-detecting\nSHA-1 implementation for both cryptographic and non-cryptographic\npurposes), we spend a significant amount of our instruction count in\nhashwrite():\n\n    $ callgrind_annotate --inclusive=yes | grep hashwrite | head -n1\n    159,998,868,413 (79.42%)  /home/ttaylorr/src/git/csum-file.c:hashwrite [/home/ttaylorr/src/git/git-pack-objects]\n\n, and the resulting \"clone\" takes 19.219 seconds of wall clock time,\n18.94 seconds of user time and 0.28 seconds of system time.\n\nCompiling with OPENSSL_SHA1_FAST=1, we spend ~60% fewer instructions in\nhashwrite():\n\n    $ callgrind_annotate --inclusive=yes | grep hashwrite | head -n1\n     59,164,001,176 (58.79%)  /home/ttaylorr/src/git/csum-file.c:hashwrite [/home/ttaylorr/src/git/git-pack-objects]\n\n, and generate the resulting \"clone\" much faster, in only 11.597 seconds\nof wall time, 11.37 seconds of user time, and 0.23 seconds of system\ntime, for a ~40% speed-up.\n\nSigned-off-by: Taylor Blau <me@ttaylorr.com>","shortMessageHtmlLink":"csum-file.c: use fast SHA-1 implementation when available"}},{"before":"0ed599b9a7e5c032526f9c2928de2c49eb896be2","after":"1d7be4aa7ffad78945940ee87b120f5914d59fa4","ref":"refs/heads/meta","pushedAt":"2024-09-05T14:37:46.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"ttaylorr","name":"Taylor Blau","path":"/ttaylorr","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/443245?s=80&v=4"},"commit":{"message":"config/config.mak: do not build with NO_OPENSSL","shortMessageHtmlLink":"config/config.mak: do not build with NO_OPENSSL"}},{"before":"a0ba742171981d7b8f0f481206669a25d2162d6e","after":"0ed599b9a7e5c032526f9c2928de2c49eb896be2","ref":"refs/heads/meta","pushedAt":"2024-09-05T14:37:28.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"ttaylorr","name":"Taylor Blau","path":"/ttaylorr","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/443245?s=80&v=4"},"commit":{"message":"Meta: steal Peff's installation tricks","shortMessageHtmlLink":"Meta: steal Peff's installation tricks"}},{"before":null,"after":"e8f5cbd280cc07f68014bd4024d55a740374b349","ref":"refs/heads/tb/fast-sha1","pushedAt":"2024-09-01T16:03:37.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"ttaylorr","name":"Taylor Blau","path":"/ttaylorr","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/443245?s=80&v=4"},"commit":{"message":"csum-file.c: use fast SHA-1 implementation when available\n\nUpdate hashwrite() and friends to use the fast_-variants of hashing\nfunctions, calling for e.g., \"the_hash_algo->fast_update_fn()\" instead\nof \"the_hash_algo->update_fn()\".\n\nThese callers only use the_hash_algo to produce a checksum, which we\ndepend on for data integrity, but not for cryptographic purposes, so\nthese callers are safe to use the fast (and potentially non-collision\ndetecting) SHA-1 implementation.\n\nTo time this, I took a freshly packed copy of linux.git, and ran the\nfollowing with and without the OPENSSL_SHA1_FAST=1 build-knob. Both\nversions were compiled with -O3:\n\n    $ git for-each-ref --format='%(objectname)' refs/heads refs/tags >in\n    $ valgrind --tool=callgrind ~/src/git/git-pack-objects \\\n        --revs --stdout --all-progress --use-bitmap-index <in >/dev/null\n\nWithout OPENSSL_SHA1_FAST=1 (that is, using the collision-detecting\nSHA-1 implementation for both cryptographic and non-cryptographic\npurposes), we spend a significant amount of our instruction count in\nhashwrite():\n\n    $ callgrind_annotate --inclusive=yes | grep hashwrite | head -n1\n    159,998,868,413 (79.42%)  /home/ttaylorr/src/git/csum-file.c:hashwrite [/home/ttaylorr/src/git/git-pack-objects]\n\n, and the resulting \"clone\" takes 19.219 seconds of wall clock time,\n18.94 seconds of user time and 0.28 seconds of system time.\n\nCompiling with OPENSSL_SHA1_FAST=1, we spend ~60% fewer instructions in\nhashwrite():\n\n    $ callgrind_annotate --inclusive=yes | grep hashwrite | head -n1\n     59,164,001,176 (58.79%)  /home/ttaylorr/src/git/csum-file.c:hashwrite [/home/ttaylorr/src/git/git-pack-objects]\n\n, and generate the resulting \"clone\" much faster, in only 11.597 seconds\nof wall time, 11.37 seconds of user time, and 0.23 seconds of system\ntime, for a ~40% speed-up.\n\nSigned-off-by: Taylor Blau <me@ttaylorr.com>","shortMessageHtmlLink":"csum-file.c: use fast SHA-1 implementation when available"}},{"before":null,"after":"82754d92509e364e96fe35ca20eb709eb6f38641","ref":"refs/heads/tb/multi-pack-reuse-cleanups","pushedAt":"2024-08-27T20:59:48.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"ttaylorr","name":"Taylor Blau","path":"/ttaylorr","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/443245?s=80&v=4"},"commit":{"message":"builtin/pack-objects.c: do not open-code `MAX_PACK_OBJECT_HEADER`\n\nThe function `write_reused_pack_one()` defines an header to store the\nOFS_DELTA header, but uses the constant \"10\" instead of\n\"MAX_PACK_OBJECT_HEADER\" (as is done elsewhere in the same patch, circa\nbb514de356c (pack-objects: improve partial packfile reuse, 2019-12-18)).\n\nDeclare the `ofs_header` field to be sized according to\n`MAX_PACK_OBJECT_HEADER` (which is 10, as defined in \"pack.h\") instead\nof the constant 10.\n\nSigned-off-by: Taylor Blau <me@ttaylorr.com>","shortMessageHtmlLink":"builtin/pack-objects.c: do not open-code <code>MAX_PACK_OBJECT_HEADER</code>"}},{"before":"da34cc944126a4dce613cb5f1c4f3f2f82cbfce4","after":"afefb4555750661ffd2c573a33d92f8fcb9f435a","ref":"refs/heads/tb/incremental-midx-bitmaps","pushedAt":"2024-08-15T22:29:34.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"ttaylorr","name":"Taylor Blau","path":"/ttaylorr","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/443245?s=80&v=4"},"commit":{"message":"midx: implement writing incremental MIDX bitmaps\n\nNow that the pack-bitmap machinery has learned how to read and interact\nwith an incremental MIDX bitmap, teach the pack-bitmap-write.c machinery\n(and relevant callers from within the MIDX machinery) to write such\nbitmaps.\n\nThe details for doing so are mostly straightforward. The main changes\nare as follows:\n\n  - find_object_pos() now makes use of an extra MIDX parameter which is\n    used to locate the bit positions of objects which are from previous\n    layers (and thus do not exist in the current layer's pack_order\n    field).\n\n    (Note also that the pack_order field is moved into struct\n    write_midx_context to further simplify the callers for\n    write_midx_bitmap()).\n\n  - bitmap_writer_build_type_index() first determines how many objects\n    precede the current bitmap layer and offsets the bits it sets in\n    each respective type-level bitmap by that amount so they can be OR'd\n    together.\n\nSigned-off-by: Taylor Blau <me@ttaylorr.com>","shortMessageHtmlLink":"midx: implement writing incremental MIDX bitmaps"}},{"before":"2f51ead083bc71acf4bb7ea41b8b1925be547f54","after":"da34cc944126a4dce613cb5f1c4f3f2f82cbfce4","ref":"refs/heads/tb/incremental-midx-bitmaps","pushedAt":"2024-08-15T21:02:03.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"ttaylorr","name":"Taylor Blau","path":"/ttaylorr","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/443245?s=80&v=4"},"commit":{"message":"midx: implement writing incremental MIDX bitmaps\n\nNow that the pack-bitmap machinery has learned how to read and interact\nwith an incremental MIDX bitmap, teach the pack-bitmap-write.c machinery\n(and relevant callers from within the MIDX machinery) to write such\nbitmaps.\n\nThe details for doing so are mostly straightforward. The main changes\nare as follows:\n\n  - find_object_pos() now makes use of an extra MIDX parameter which is\n    used to locate the bit positions of objects which are from previous\n    layers (and thus do not exist in the current layer's pack_order\n    field).\n\n    (Note also that the pack_order field is moved into struct\n    write_midx_context to further simplify the callers for\n    write_midx_bitmap()).\n\n  - bitmap_writer_build_type_index() first determines how many objects\n    precede the current bitmap layer and offsets the bits it sets in\n    each respective type-level bitmap by that amount so they can be OR'd\n    together.\n\nSigned-off-by: Taylor Blau <me@ttaylorr.com>","shortMessageHtmlLink":"midx: implement writing incremental MIDX bitmaps"}},{"before":"7d45992d9366ed49121a32c2541f0dc77c05710e","after":"2f51ead083bc71acf4bb7ea41b8b1925be547f54","ref":"refs/heads/tb/incremental-midx-bitmaps","pushedAt":"2024-08-15T18:30:32.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"ttaylorr","name":"Taylor Blau","path":"/ttaylorr","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/443245?s=80&v=4"},"commit":{"message":"midx: implement writing incremental MIDX bitmaps\n\nNow that the pack-bitmap machinery has learned how to read and interact\nwith an incremental MIDX bitmap, teach the pack-bitmap-write.c machinery\n(and relevant callers from within the MIDX machinery) to write such\nbitmaps.\n\nThe details for doing so are mostly straightforward. The main changes\nare as follows:\n\n  - find_object_pos() now makes use of an extra MIDX parameter which is\n    used to locate the bit positions of objects which are from previous\n    layers (and thus do not exist in the current layer's pack_order\n    field).\n\n    (Note also that the pack_order field is moved into struct\n    write_midx_context to further simplify the callers for\n    write_midx_bitmap()).\n\n  - bitmap_writer_build_type_index() first determines how many objects\n    precede the current bitmap layer and offsets the bits it sets in\n    each respective type-level bitmap by that amount so they can be OR'd\n    together.\n\nSigned-off-by: Taylor Blau <me@ttaylorr.com>","shortMessageHtmlLink":"midx: implement writing incremental MIDX bitmaps"}},{"before":"afdb8b5837cb75346c3ac83bb70d5b449e23fdef","after":"2f51ead083bc71acf4bb7ea41b8b1925be547f54","ref":"refs/heads/tb/incremental-midx-bitmaps-alt","pushedAt":"2024-08-15T18:30:08.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"ttaylorr","name":"Taylor Blau","path":"/ttaylorr","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/443245?s=80&v=4"},"commit":{"message":"midx: implement writing incremental MIDX bitmaps\n\nNow that the pack-bitmap machinery has learned how to read and interact\nwith an incremental MIDX bitmap, teach the pack-bitmap-write.c machinery\n(and relevant callers from within the MIDX machinery) to write such\nbitmaps.\n\nThe details for doing so are mostly straightforward. The main changes\nare as follows:\n\n  - find_object_pos() now makes use of an extra MIDX parameter which is\n    used to locate the bit positions of objects which are from previous\n    layers (and thus do not exist in the current layer's pack_order\n    field).\n\n    (Note also that the pack_order field is moved into struct\n    write_midx_context to further simplify the callers for\n    write_midx_bitmap()).\n\n  - bitmap_writer_build_type_index() first determines how many objects\n    precede the current bitmap layer and offsets the bits it sets in\n    each respective type-level bitmap by that amount so they can be OR'd\n    together.\n\nSigned-off-by: Taylor Blau <me@ttaylorr.com>","shortMessageHtmlLink":"midx: implement writing incremental MIDX bitmaps"}},{"before":null,"after":"c9a64b1d2a9d6b3fe1f5fb0a7303e043114fcd8f","ref":"refs/heads/tb/pseudo-merge-closure","pushedAt":"2024-08-15T16:51:42.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"ttaylorr","name":"Taylor Blau","path":"/ttaylorr","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/443245?s=80&v=4"},"commit":{"message":"pseudo-merge.c: ensure pseudo-merge groups are closed\n\nWhen generating pseudo-merge bitmaps, it's possible that concurrent\nreference updates may reveal some pseudo-merge candidates which reach\nobjects that are not contained in the bitmap's pack or pseudo-pack\norder (in the case of MIDX bitmaps).\n\nThe latter case is relatively easy to demonstrate: if we generate a MIDX\nbitmap with only half of the repository packed, then the unpacked\ncontents are not part of the MIDX's object order.\n\nIf we happen to select one or more commit(s) from the unpacked portion\nof the repository for inclusion in a pseudo-merge, we'll get the\nfollowing message when trying to generate its bitmap:\n\n    $ git multi-pack-index write --bitmap\n    [...]\n    Selecting pseudo-merge commits: 100% (1/1), done.\n    warning: Failed to write bitmap index. Packfile doesn't have full closure (object ... is missing)\n    Building bitmaps:  50% (1/2), done.\n    error: could not write multi-pack bitmap\n\n, and the attempted bitmap write will fail, leaving the repository\nwithout a current bitmap.\n\nRectify this by ensuring that the commits which are pseudo-merge\ncandidates can only be so if they appear somewhere in the packing order.\n\nThis is sufficient, since we know that the original packing order is\nclosed under reachability, so if a commit appears in that list as a\npotential pseudo-merge candidate, we know that everything reachable from\nit also appears in the list (and thus the candidate is a good one).\n\nNoticed-by: Jeff King <peff@peff.net>\nSigned-off-by: Taylor Blau <me@ttaylorr.com>","shortMessageHtmlLink":"pseudo-merge.c: ensure pseudo-merge groups are closed"}},{"before":"cffeabc97478e555d73fa9cfcf390698a6a65963","after":"afdb8b5837cb75346c3ac83bb70d5b449e23fdef","ref":"refs/heads/tb/incremental-midx-bitmaps-alt","pushedAt":"2024-08-14T20:08:33.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"ttaylorr","name":"Taylor Blau","path":"/ttaylorr","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/443245?s=80&v=4"},"commit":{"message":"midx: implement writing incremental MIDX bitmaps\n\nNow that the pack-bitmap machinery has learned how to read and interact\nwith an incremental MIDX bitmap, teach the pack-bitmap-write.c machinery\n(and relevant callers from within the MIDX machinery) to write such\nbitmaps.\n\nThe details for doing so are mostly straightforward. The main changes\nare as follows:\n\n  - find_object_pos() now makes use of an extra MIDX parameter which is\n    used to locate the bit positions of objects which are from previous\n    layers (and thus do not exist in the current layer's pack_order\n    field).\n\n    (Note also that the pack_order field is moved into struct\n    write_midx_context to further simplify the callers for\n    write_midx_bitmap()).\n\n  - bitmap_writer_build_type_index() first determines how many objects\n    precede the current bitmap layer and offsets the bits it sets in\n    each respective type-level bitmap by that amount so they can be OR'd\n    together.\n\nSigned-off-by: Taylor Blau <me@ttaylorr.com>","shortMessageHtmlLink":"midx: implement writing incremental MIDX bitmaps"}},{"before":"69b96b837e90d05ae5d600fc66e535b4adcd518e","after":"cffeabc97478e555d73fa9cfcf390698a6a65963","ref":"refs/heads/tb/incremental-midx-bitmaps-alt","pushedAt":"2024-08-14T19:42:35.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"ttaylorr","name":"Taylor Blau","path":"/ttaylorr","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/443245?s=80&v=4"},"commit":{"message":"midx: implement writing incremental MIDX bitmaps\n\nNow that the pack-bitmap machinery has learned how to read and interact\nwith an incremental MIDX bitmap, teach the pack-bitmap-write.c machinery\n(and relevant callers from within the MIDX machinery) to write such\nbitmaps.\n\nThe details for doing so are mostly straightforward. The main changes\nare as follows:\n\n  - find_object_pos() now makes use of an extra MIDX parameter which is\n    used to locate the bit positions of objects which are from previous\n    layers (and thus do not exist in the current layer's pack_order\n    field).\n\n    (Note also that the pack_order field is moved into struct\n    write_midx_context to further simplify the callers for\n    write_midx_bitmap()).\n\n  - bitmap_writer_build_type_index() first determines how many objects\n    precede the current bitmap layer and offsets the bits it sets in\n    each respective type-level bitmap by that amount so they can be OR'd\n    together.\n\nSigned-off-by: Taylor Blau <me@ttaylorr.com>","shortMessageHtmlLink":"midx: implement writing incremental MIDX bitmaps"}},{"before":null,"after":"69b96b837e90d05ae5d600fc66e535b4adcd518e","ref":"refs/heads/tb/incremental-midx-bitmaps-alt","pushedAt":"2024-08-14T16:01:12.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"ttaylorr","name":"Taylor Blau","path":"/ttaylorr","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/443245?s=80&v=4"},"commit":{"message":"midx: incremental MIDX bitmap writes\n\nSigned-off-by: Taylor Blau <me@ttaylorr.com>","shortMessageHtmlLink":"midx: incremental MIDX bitmap writes"}},{"before":"b207b71ad897f895dbebbd81c78155895781dbe9","after":"7d45992d9366ed49121a32c2541f0dc77c05710e","ref":"refs/heads/tb/incremental-midx-bitmaps","pushedAt":"2024-08-14T00:12:27.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"ttaylorr","name":"Taylor Blau","path":"/ttaylorr","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/443245?s=80&v=4"},"commit":{"message":"pack-bitmap.c: WIP filter_bitmap_blob_limit()\n\nSigned-off-by: Taylor Blau <me@ttaylorr.com>","shortMessageHtmlLink":"pack-bitmap.c: WIP filter_bitmap_blob_limit()"}},{"before":"6757a636eba33bffe4e23fd8cff2eedc079f0ed5","after":"b207b71ad897f895dbebbd81c78155895781dbe9","ref":"refs/heads/tb/incremental-midx-bitmaps","pushedAt":"2024-08-14T00:09:58.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"ttaylorr","name":"Taylor Blau","path":"/ttaylorr","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/443245?s=80&v=4"},"commit":{"message":"pack-bitmap.c: WIP filter_bitmap_blob_limit()\n\nSigned-off-by: Taylor Blau <me@ttaylorr.com>","shortMessageHtmlLink":"pack-bitmap.c: WIP filter_bitmap_blob_limit()"}},{"before":"e2b5961b4556122e594b657efe2f1d3337368cdd","after":"5d467d38a8d454228032610b3506040b63eb6369","ref":"refs/heads/tb/incremental-midx","pushedAt":"2024-08-06T15:38:12.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"ttaylorr","name":"Taylor Blau","path":"/ttaylorr","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/443245?s=80&v=4"},"commit":{"message":"midx: implement support for writing incremental MIDX chains\n\nNow that the rest of the MIDX subsystem and relevant callers have been\nupdated to learn about how to read and process incremental MIDX chains,\nlet's finally update the implementation in `write_midx_internal()` to be\nable to write incremental MIDX chains.\n\nThis new feature is available behind the `--incremental` option for the\n`multi-pack-index` builtin, like so:\n\n    $ git multi-pack-index write --incremental\n\nThe implementation for doing so is relatively straightforward, and boils\ndown to a handful of different kinds of changes implemented in this\npatch:\n\n  - The `compute_sorted_entries()` function is taught to reject objects\n    which appear in any existing MIDX layer.\n\n  - Functions like `write_midx_revindex()` are adjusted to write\n    pack_order values which are offset by the number of objects in the\n    base MIDX layer.\n\n  - The end of `write_midx_internal()` is adjusted to move\n    non-incremental MIDX files when necessary (i.e. when creating an\n    incremental chain with an existing non-incremental MIDX in the\n    repository).\n\nThere are a handful of other changes that are introduced, like new\nfunctions to clear incremental MIDX files that are unrelated to the\ncurrent chain (using the same \"keep_hash\" mechanism as in the\nnon-incremental case).\n\nThe tests explicitly exercising the new incremental MIDX feature are\nrelatively limited for two reasons:\n\n  1. Most of the \"interesting\" behavior is already thoroughly covered in\n     t5319-multi-pack-index.sh, which handles the core logic of reading\n     objects through a MIDX.\n\n     The new tests in t5334-incremental-multi-pack-index.sh are mostly\n     focused on creating and destroying incremental MIDXs, as well as\n     stitching their results together across layers.\n\n  2. A new GIT_TEST environment variable is added called\n     \"GIT_TEST_MULTI_PACK_INDEX_WRITE_INCREMENTAL\", which modifies the\n     entire test suite to write incremental MIDXs after repacking when\n     combined with the \"GIT_TEST_MULTI_PACK_INDEX\" variable.\n\n     This exercises the long tail of other interesting behavior that is\n     defined implicitly throughout the rest of the CI suite. It is\n     likewise added to the linux-TEST-vars job.\n\nSigned-off-by: Taylor Blau <me@ttaylorr.com>","shortMessageHtmlLink":"midx: implement support for writing incremental MIDX chains"}},{"before":null,"after":"95cdc30bad38f464b37e87d78f38e1d91c9e083b","ref":"refs/heads/tb/t7704-race-on-slow-systems","pushedAt":"2024-08-05T19:37:17.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"ttaylorr","name":"Taylor Blau","path":"/ttaylorr","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/443245?s=80&v=4"},"commit":{"message":"t/t7704-repack-cruft.sh: avoid failures during long-running tests\n\nOn systems where running t7704.09 takes longer than 10 seconds, the test\ncan fail.\n\nThe test works by doing the following:\n\n  - First write three unreachable objects, backdating the mtime for a\n    single object ($foo) which we expect to prune.\n\n  - Repack the repository into a pack containing reachable objects, and\n    another three cruft packs, each containing one of the objects\n    written in the previous step.\n\n  - Backdate the mtimes of the cruft pack *.mtimes files themselves.\n    (Note that this does not affect what is pruned further down in the\n    test, but is done to ensure that the cruft packs are rewritten\n    during that step).\n\n  - Then repack with --cruft-expiration=10.seconds.ago, expecting to\n    prune one of the three unreachable objects written in the first\n    step.\n\n  - Assert that the surviving cruft packs were rewritten, object $foo is\n    pruned, and unreachable objects $bar, and $baz remain in the\n    repository.\n\nIf longer than 10 seconds pass between writing the three unreachable\nobjects (the first step) and the \"git repack --cruft\" (the fourth step),\nwe will mistakenly prune more objects than expected, causing the test to\nfail.\n\nThe $foo object which we expect to prune has its mtime set back to\n10,000 seconds relative to the current time, but we prune it with a\ncutoff of 10.seconds.ago.\n\nInstead, set the cutoff to be 1,000 seconds to give the test much longer\ntime to run without failing. This helps platforms where running\nindividual tests can perform slowly, on my machine this test runs much\nmore quickly:\n\n    $ hyperfine './t7704-repack-cruft.sh --run=9'\n    Benchmark 1: ./t7704-repack-cruft.sh --run=9\n      Time (mean ± σ):     647.4 ms ±  30.7 ms    [User: 528.5 ms, System: 124.1 ms]\n      Range (min … max):   594.1 ms … 696.5 ms    10 runs\n\nReported-by: Randall Becker <randall.becker@nexbridge.com>\nSigned-off-by: Taylor Blau <me@ttaylorr.com>","shortMessageHtmlLink":"t/t7704-repack-cruft.sh: avoid failures during long-running tests"}},{"before":null,"after":"c78bacfa8fb274fbb48f259b13f4f30253932f69","ref":"refs/heads/tb/config-fixed-value-implied-true","pushedAt":"2024-08-01T17:07:05.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"ttaylorr","name":"Taylor Blau","path":"/ttaylorr","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/443245?s=80&v=4"},"commit":{"message":"config.c: avoid segfault with --fixed-value and valueless config\n\nWhen using `--fixed-value` with a key whose value is left empty (implied\nas being \"true\"), 'git config' may crash when invoked like either of:\n\n    $ git config set --file=config --value=value --fixed-value \\\n        section.key pattern\n    $ git config --file=config --fixed-value section.key value pattern\n\nThe original bugreport[1] bisects to 00bbdde141 (builtin/config:\nintroduce \"set\" subcommand, 2024-05-06), which is a red-herring, since\nthe original bugreport uses the new 'git config set' invocation.\n\nThe behavior likely bisects back to c90702a1f6 (config: plumb\n--fixed-value into config API, 2020-11-25), which introduces the new\n--fixed-value option in the first place.\n\nLooking at the relevant frame from a failed process's coredump, the\ncrash appears in config.c::matches() like so:\n\n    (gdb) up\n    #1  0x000055b3e8b06022 in matches (key=0x55b3ea894360 \"section.key\", value=0x0,\n        store=0x7ffe99076eb0) at config.c:2884\n    2884\t\t\treturn !strcmp(store->fixed_value, value);\n\nwhere we are trying to compare the `--fixed-value` argument to `value`,\nwhich is NULL.\n\nAvoid attempting to match `--fixed-value` for configuration keys with no\nexplicit value. A future patch could consider the empty value to mean\n\"true\", \"yes\", \"on\", etc. when invoked with `--type=bool`, but let's\npunt on that for now in the name of avoiding the segfault.\n\n[1]: https://lore.kernel.org/git/CANrWfmTek1xErBLrnoyhHN+gWU+rw14y6SQ+abZyzGoaBjmiKA@mail.gmail.com/\n\nReported-by: Han Jiang <jhcarl0814@gmail.com>\nSigned-off-by: Taylor Blau <me@ttaylorr.com>","shortMessageHtmlLink":"config.c: avoid segfault with --fixed-value and valueless config"}},{"before":null,"after":"f5d6ded8f6001415802a25ac7728ed43f8905cde","ref":"refs/heads/tb/2.46-relnotes-typofix","pushedAt":"2024-07-22T22:03:15.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"ttaylorr","name":"Taylor Blau","path":"/ttaylorr","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/443245?s=80&v=4"},"commit":{"message":"Documentation/RelNotes/2.46.0.txt: fix typo\n\nThe sentence describing changes to the bundle URI mechanism ends in two\n'..' instead of one '.'.\n\nSigned-off-by: Taylor Blau <me@ttaylorr.com>","shortMessageHtmlLink":"Documentation/RelNotes/2.46.0.txt: fix typo"}},{"before":"3e3ec20117397917d4c3db67161e7c76ce42660c","after":"6757a636eba33bffe4e23fd8cff2eedc079f0ed5","ref":"refs/heads/tb/incremental-midx-bitmaps","pushedAt":"2024-07-17T21:13:21.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"ttaylorr","name":"Taylor Blau","path":"/ttaylorr","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/443245?s=80&v=4"},"commit":{"message":"midx: incremental MIDX bitmap writes","shortMessageHtmlLink":"midx: incremental MIDX bitmap writes"}},{"before":"a67bdf15a68f4f0ba071576cf80a0b3b51e11537","after":"e2b5961b4556122e594b657efe2f1d3337368cdd","ref":"refs/heads/tb/incremental-midx","pushedAt":"2024-07-17T21:12:59.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"ttaylorr","name":"Taylor Blau","path":"/ttaylorr","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/443245?s=80&v=4"},"commit":{"message":"midx: implement support for writing incremental MIDX chains\n\nNow that the rest of the MIDX subsystem and relevant callers have been\nupdated to learn about how to read and process incremental MIDX chains,\nlet's finally update the implementation in `write_midx_internal()` to be\nable to write incremental MIDX chains.\n\nThis new feature is available behind the `--incremental` option for the\n`multi-pack-index` builtin, like so:\n\n    $ git multi-pack-index write --incremental\n\nThe implementation for doing so is relatively straightforward, and boils\ndown to a handful of different kinds of changes implemented in this\npatch:\n\n  - The `compute_sorted_entries()` function is taught to reject objects\n    which appear in any existing MIDX layer.\n\n  - Functions like `write_midx_revindex()` are adjusted to write\n    pack_order values which are offset by the number of objects in the\n    base MIDX layer.\n\n  - The end of `write_midx_internal()` is adjusted to move\n    non-incremental MIDX files when necessary (i.e. when creating an\n    incremental chain with an existing non-incremental MIDX in the\n    repository).\n\nThere are a handful of other changes that are introduced, like new\nfunctions to clear incremental MIDX files that are unrelated to the\ncurrent chain (using the same \"keep_hash\" mechanism as in the\nnon-incremental case).\n\nThe tests explicitly exercising the new incremental MIDX feature are\nrelatively limited for two reasons:\n\n  1. Most of the \"interesting\" behavior is already thoroughly covered in\n     t5319-multi-pack-index.sh, which handles the core logic of reading\n     objects through a MIDX.\n\n     The new tests in t5334-incremental-multi-pack-index.sh are mostly\n     focused on creating and destroying incremental MIDXs, as well as\n     stitching their results together across layers.\n\n  2. A new GIT_TEST environment variable is added called\n     \"GIT_TEST_MULTI_PACK_INDEX_WRITE_INCREMENTAL\", which modifies the\n     entire test suite to write incremental MIDXs after repacking when\n     combined with the \"GIT_TEST_MULTI_PACK_INDEX\" variable.\n\n     This exercises the long tail of other interesting behavior that is\n     defined implicitly throughout the rest of the CI suite. It is\n     likewise added to the linux-TEST-vars job.\n\nSigned-off-by: Taylor Blau <me@ttaylorr.com>","shortMessageHtmlLink":"midx: implement support for writing incremental MIDX chains"}},{"before":"13aebd62f0b67390876fecbcbb20d2e75e82cad0","after":"3e3ec20117397917d4c3db67161e7c76ce42660c","ref":"refs/heads/tb/incremental-midx-bitmaps","pushedAt":"2024-07-17T19:43:49.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"ttaylorr","name":"Taylor Blau","path":"/ttaylorr","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/443245?s=80&v=4"},"commit":{"message":"midx: incremental MIDX bitmap writes","shortMessageHtmlLink":"midx: incremental MIDX bitmap writes"}},{"before":"3504a7074006bbae84af83b92405103ba7ace796","after":"a67bdf15a68f4f0ba071576cf80a0b3b51e11537","ref":"refs/heads/tb/incremental-midx","pushedAt":"2024-07-17T19:43:49.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"ttaylorr","name":"Taylor Blau","path":"/ttaylorr","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/443245?s=80&v=4"},"commit":{"message":"midx: implement support for writing incremental MIDX chains\n\nNow that the rest of the MIDX subsystem and relevant callers have been\nupdated to learn about how to read and process incremental MIDX chains,\nlet's finally update the implementation in `write_midx_internal()` to be\nable to write incremental MIDX chains.\n\nThis new feature is available behind the `--incremental` option for the\n`multi-pack-index` builtin, like so:\n\n    $ git multi-pack-index write --incremental\n\nThe implementation for doing so is relatively straightforward, and boils\ndown to a handful of different kinds of changes implemented in this\npatch:\n\n  - The `compute_sorted_entries()` function is taught to reject objects\n    which appear in any existing MIDX layer.\n\n  - Functions like `write_midx_revindex()` are adjusted to write\n    pack_order values which are offset by the number of objects in the\n    base MIDX layer.\n\n  - The end of `write_midx_internal()` is adjusted to move\n    non-incremental MIDX files when necessary (i.e. when creating an\n    incremental chain with an existing non-incremental MIDX in the\n    repository).\n\nThere are a handful of other changes that are introduced, like new\nfunctions to clear incremental MIDX files that are unrelated to the\ncurrent chain (using the same \"keep_hash\" mechanism as in the\nnon-incremental case).\n\nThe tests explicitly exercising the new incremental MIDX feature are\nrelatively limited for two reasons:\n\n  1. Most of the \"interesting\" behavior is already thoroughly covered in\n     t5319-multi-pack-index.sh, which handles the core logic of reading\n     objects through a MIDX.\n\n     The new tests in t5334-incremental-multi-pack-index.sh are mostly\n     focused on creating and destroying incremental MIDXs, as well as\n     stitching their results together across layers.\n\n  2. A new GIT_TEST environment variable is added called\n     \"GIT_TEST_MULTI_PACK_INDEX_WRITE_INCREMENTAL\", which modifies the\n     entire test suite to write incremental MIDXs after repacking when\n     combined with the \"GIT_TEST_MULTI_PACK_INDEX\" variable.\n\n     This exercises the long tail of other interesting behavior that is\n     defined implicitly throughout the rest of the CI suite. It is\n     likewise added to the linux-TEST-vars job.\n\nSigned-off-by: Taylor Blau <me@ttaylorr.com>","shortMessageHtmlLink":"midx: implement support for writing incremental MIDX chains"}},{"before":"1e1586e4ed626bde864339c10570bc0e73f0ab97","after":"04f5a52757cd92347271e24f7cbdfe15dafce3b7","ref":"refs/heads/master","pushedAt":"2024-07-17T18:54:43.000Z","pushType":"push","commitsCount":242,"pusher":{"login":"ttaylorr","name":"Taylor Blau","path":"/ttaylorr","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/443245?s=80&v=4"},"commit":{"message":"Post 2.46-rc0 batch #2\n\nSigned-off-by: Junio C Hamano <gitster@pobox.com>","shortMessageHtmlLink":"Post 2.46-rc0 batch #2"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEr0PzbwA","startCursor":null,"endCursor":null}},"title":"Activity · ttaylorr/git"}