{"thread":{"id":"55491","subject":"What's cooking (draft for #4's issue this month)","startedAt":"2021-04-14T01:11:46Z","lastAt":"2021-04-19T23:14:42Z","messageCount":14,"participants":["Junio C Hamano","Patrick Steinhardt","brian m. carlson","Jeff King","Han-Wen Nienhuys"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"421943","messageId":"xmqqmtu1zn3o.fsf@gitster.g","threadId":"55491","inReplyTo":null,"subject":"What's cooking (draft for #4's issue this month)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-04-14T01:11:39Z","receivedAt":"2021-04-14T01:11:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"A handful of topics have been merged to 'master' as the 9th batch of\nthis cycle.\n\n    54a3917115 The ninth batch\n    e0d4a63c09 Merge branch 'vs/completion-with-set-u'\n    e6545201ad Merge branch 'ab/detox-config-gettext'\n    a9414b86ac Merge branch 'gk/gitweb-redacted-email'\n    8446b388b1 Merge branch 'cc/test-helper-bloom-usage-fix'\n    2279289e95 Merge branch 'ab/send-email-validate-errors'\n    4c6ac2da2c Merge branch 'tb/precompose-prefix-simplify'\n    1d5fbd45c4 Merge branch 'fm/user-manual-use-preface'\n    7b55441db1 Merge branch 'ab/perl-do-not-abuse-map'\n    0623669fc6 Merge branch 'tb/pack-preferred-tips-to-give-bitmap'\n    f63add4aa8 Merge branch 'jk/ref-filter-segfault-fix'\n\nAnd a few topics have been merged to 'next'.\n\n    cdadb2c621 Merge branch 'hn/reftable-tables-doc-update' into next\n    bbe18a7b3a Merge branch 'jk/pack-objects-bitmap-progress-fix' into next\n    41713a32bd Merge branch 'ah/merge-ort-ubsan-fix' into next\n    35fb0e853d Merge branch 'ab/userdiff-tests' into next\n    eb80d55a8c Merge branch 'ar/userdiff-scheme' into next\n\nOn 'seen' there are many topics that have not seen adequately\nreviews; some tests are broken near its tip (I think they pass the\nselftests by themselves).\n\n    0e76df05ca Merge branch 'ps/rev-list-object-type-filter' into seen\n    956fbceb2e ### breaks 6112 6113\n    c007303ad4 Merge branch 'bc/hash-transition-interop-part-1' into seen\n    4813f16161 ### breaks 0031\n\n"},{"id":"421959","messageId":"YHa5NE3tj/R5kF8N@ncase","threadId":"55491","inReplyTo":"xmqqmtu1zn3o.fsf@gitster.g","subject":"Re: What's cooking (draft for #4's issue this month)","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2021-04-14T09:43:16Z","receivedAt":"2021-04-14T09:43:26Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Tue, Apr 13, 2021 at 06:11:39PM -0700, Junio C Hamano wrote:\n> On 'seen' there are many topics that have not seen adequately\n> reviews; some tests are broken near its tip (I think they pass the\n> selftests by themselves).\n> \n>     0e76df05ca Merge branch 'ps/rev-list-object-type-filter' into seen\n>     956fbceb2e ### breaks 6112 6113\n>     c007303ad4 Merge branch 'bc/hash-transition-interop-part-1' into seen\n>     4813f16161 ### breaks 0031\n\nTest breakage for the rev-list filter series has been a bad interaction\nof d8883ed540 (object.c: stop supporting len == -1 in\ntype_from_string_gently(), 2021-03-28) and\nps/rev-list-object-type-filter. The following patch fixes this, which\nI'll include in my next reroll of this series.\n\ndiff --git a/list-objects-filter-options.c b/list-objects-filter-options.c\nindex 19e128ef11..33c7718a7a 100644\n--- a/list-objects-filter-options.c\n+++ b/list-objects-filter-options.c\n@@ -100,7 +100,7 @@ static int gently_parse_list_objects_filter(\n \t\treturn 1;\n\n \t} else if (skip_prefix(arg, \"object:type=\", &v0)) {\n-\t\tint type = type_from_string_gently(v0, -1);\n+\t\tint type = type_from_string_gently(v0, strlen(v0));\n \t\tif (type < 0) {\n \t\t\tstrbuf_addstr(errbuf, _(\"expected 'object:type=<type>'\"));\n \t\t\treturn 1;\n\n\nThe other breakages I see are caused by hn/reftable, where all tests in\nt0031-reftables.sh cause segfaults. The root cause seems to be that\nreading refs via the reftable backend doesn't initialize the `algo`\nfield of the OID, which is fixed via the following patch.\n\ndiff --git a/refs/reftable-backend.c b/refs/reftable-backend.c\nindex 130fd90e45..35fb7dd0a2 100644\n--- a/refs/reftable-backend.c\n+++ b/refs/reftable-backend.c\n@@ -251,10 +251,10 @@ static int reftable_ref_iterator_advance(struct ref_iterator *ref_iterator)\n \t\tri->base.flags = 0;\n \t\tswitch (ri->ref.value_type) {\n \t\tcase REFTABLE_REF_VAL1:\n-\t\t\thashcpy(ri->oid.hash, ri->ref.value.val1);\n+\t\t\toidread(&ri->oid, ri->ref.value.val1);\n \t\t\tbreak;\n \t\tcase REFTABLE_REF_VAL2:\n-\t\t\thashcpy(ri->oid.hash, ri->ref.value.val2.value);\n+\t\t\toidread(&ri->oid, ri->ref.value.val2.value);\n \t\t\tbreak;\n \t\tcase REFTABLE_REF_SYMREF: {\n \t\t\tint out_flags = 0;\n@@ -299,7 +299,7 @@ static int reftable_ref_iterator_peel(struct ref_iterator *ref_iterator,\n \tstruct git_reftable_iterator *ri =\n \t\t(struct git_reftable_iterator *)ref_iterator;\n \tif (ri->ref.value_type == REFTABLE_REF_VAL2) {\n-\t\thashcpy(peeled->hash, ri->ref.value.val2.target_value);\n+\t\toidread(peeled, ri->ref.value.val2.target_value);\n \t\treturn 0;\n \t}\n\n@@ -977,7 +977,7 @@ git_reftable_reflog_ref_iterator_advance(struct ref_iterator *ref_iterator)\n\n \t\tfree(ri->last_name);\n \t\tri->last_name = xstrdup(ri->log.refname);\n-\t\thashcpy(ri->oid.hash, ri->log.update.new_hash);\n+\t\toidread(&ri->oid, ri->log.update.new_hash);\n \t\treturn ITER_OK;\n \t}\n }\n@@ -1090,8 +1090,8 @@ static int git_reftable_for_each_reflog_ent_newest_first(\n \t\t\tbreak;\n \t\t}\n\n-\t\thashcpy(old_oid.hash, log.update.old_hash);\n-\t\thashcpy(new_oid.hash, log.update.new_hash);\n+\t\toidread(&old_oid, log.update.old_hash);\n+\t\toidread(&new_oid, log.update.new_hash);\n\n \t\tfull_committer = fmt_ident(log.update.name, log.update.email,\n \t\t\t\t\t   WANT_COMMITTER_IDENT,\n@@ -1157,8 +1157,8 @@ static int git_reftable_for_each_reflog_ent_oldest_first(\n \t\tstruct object_id new_oid;\n \t\tconst char *full_committer = \"\";\n\n-\t\thashcpy(old_oid.hash, log->update.old_hash);\n-\t\thashcpy(new_oid.hash, log->update.new_hash);\n+\t\toidread(&old_oid, log->update.old_hash);\n+\t\toidread(&new_oid, log->update.new_hash);\n\n \t\tfull_committer = fmt_ident(log->update.name, log->update.email,\n \t\t\t\t\t   WANT_COMMITTER_IDENT, NULL,\n@@ -1330,8 +1330,8 @@ git_reftable_reflog_expire(struct ref_store *ref_store, const char *refname,\n \t\tif (err > 0 || strcmp(log.refname, refname)) {\n \t\t\tbreak;\n \t\t}\n-\t\thashcpy(ooid.hash, log.update.old_hash);\n-\t\thashcpy(noid.hash, log.update.new_hash);\n+\t\toidread(&ooid, log.update.old_hash);\n+\t\toidread(&noid, log.update.new_hash);\n\n \t\tif (should_prune_fn(&ooid, &noid, log.update.email,\n \t\t\t\t    (timestamp_t)log.update.time,\n@@ -1410,7 +1410,7 @@ static int git_reftable_read_raw_ref(struct ref_store *ref_store,\n \t\tstrbuf_addstr(referent, ref.value.symref);\n \t\t*type |= REF_ISSYMREF;\n \t} else if (reftable_ref_record_val1(&ref) != NULL) {\n-\t\thashcpy(oid->hash, reftable_ref_record_val1(&ref));\n+\t\toidread(oid, reftable_ref_record_val1(&ref));\n \t} else {\n \t\t*type |= REF_ISBROKEN;\n \t\terrno = EINVAL;\n\n\nPatrick\n"},{"id":"421986","messageId":"xmqqeefcy35i.fsf@gitster.g","threadId":"55491","inReplyTo":"YHa5NE3tj/R5kF8N@ncase","subject":"Re: What's cooking (draft for #4's issue this month)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-04-14T21:20:09Z","receivedAt":"2021-04-14T21:20:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Patrick Steinhardt <ps@pks.im> writes:\n\n> On Tue, Apr 13, 2021 at 06:11:39PM -0700, Junio C Hamano wrote:\n>> On 'seen' there are many topics that have not seen adequately\n>> reviews; some tests are broken near its tip (I think they pass the\n>> selftests by themselves).\n>> \n>>     0e76df05ca Merge branch 'ps/rev-list-object-type-filter' into seen\n>>     956fbceb2e ### breaks 6112 6113\n>>     c007303ad4 Merge branch 'bc/hash-transition-interop-part-1' into seen\n>>     4813f16161 ### breaks 0031\n>\n> Test breakage for the rev-list filter series has been a bad interaction\n> of d8883ed540 (object.c: stop supporting len == -1 in\n> type_from_string_gently(), 2021-03-28) and\n> ps/rev-list-object-type-filter.\n\nYuck.  The commit d8883ed5 (object.c: stop supporting len == -1 in\ntype_from_string_gently(), 2021-03-28) by itself may have meant\nwell, but in an environment where concurrent group development is\nthe norm, it is a change that can unnecessarily break other topics\neasily, like it just did.\n\nPerhaps a band-aid like this may be necessary.\n\ndiff --git i/object.c w/object.c\nindex 68de229f1a..b4bde9e444 100644\n--- i/object.c\n+++ w/object.c\n@@ -39,6 +39,9 @@ int type_from_string_gently(const char *str, ssize_t len, int gentle)\n {\n \tint i;\n \n+\tif (len < 0)\n+\t\tBUG(\"type-from-string-gently no longer allows unspecified length\");\n+\n \tfor (i = 1; i < ARRAY_SIZE(object_type_strings); i++)\n \t\tif (!strncmp(str, object_type_strings[i], len) &&\n \t\t    object_type_strings[i][len] == '\\0')\n\n> The following patch fixes this, which\n> I'll include in my next reroll of this series.\n\nThanks.\n\n> diff --git a/list-objects-filter-options.c b/list-objects-filter-options.c\n> index 19e128ef11..33c7718a7a 100644\n> --- a/list-objects-filter-options.c\n> +++ b/list-objects-filter-options.c\n> @@ -100,7 +100,7 @@ static int gently_parse_list_objects_filter(\n>  \t\treturn 1;\n>\n>  \t} else if (skip_prefix(arg, \"object:type=\", &v0)) {\n> -\t\tint type = type_from_string_gently(v0, -1);\n> +\t\tint type = type_from_string_gently(v0, strlen(v0));\n>  \t\tif (type < 0) {\n>  \t\t\tstrbuf_addstr(errbuf, _(\"expected 'object:type=<type>'\"));\n>  \t\t\treturn 1;\n\n"},{"id":"421987","messageId":"xmqq7dl4y2lu.fsf@gitster.g","threadId":"55491","inReplyTo":"YHa5NE3tj/R5kF8N@ncase","subject":"Re: What's cooking (draft for #4's issue this month)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-04-14T21:31:57Z","receivedAt":"2021-04-14T21:32:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Patrick Steinhardt <ps@pks.im> writes:\n\n> The other breakages I see are caused by hn/reftable, where all tests in\n> t0031-reftables.sh cause segfaults. The root cause seems to be that\n> reading refs via the reftable backend doesn't initialize the `algo`\n> field of the OID, which is fixed via the following patch.\n\nOK.  On 'master' without bc/hash-transition-interop-part-1,\nhashcpy() and oidread() both use the size from the_hash_algo\nbut with the topic, oidread() becomes the way to declare that\nthe given oid uses the_hash_algo.\n\nstatic inline void hashcpy(unsigned char *sha_dst, const unsigned char *sha_src)\n{\n\tmemcpy(sha_dst, sha_src, the_hash_algo->rawsz);\n}\n\nstatic inline void oidread(struct object_id *oid, const unsigned char *hash)\n{\n\tsize_t rawsz = the_hash_algo->rawsz;\n\tmemcpy(oid->hash, hash, rawsz);\n\tmemset(oid->hash + rawsz, 0, GIT_MAX_RAWSZ - rawsz);\n\toid->algo = hash_algo_by_ptr(the_hash_algo);\n}\n\nSo the patch makes sense to directly squashed into hn/reftable topic\nto (1) be a benign no-op in the master and to (2) fix an expected\nsemantic conflict with bc/hash-transition-interop-part-1 topic.\n\nThanks.\n\n\n\n> diff --git a/refs/reftable-backend.c b/refs/reftable-backend.c\n> index 130fd90e45..35fb7dd0a2 100644\n> --- a/refs/reftable-backend.c\n> +++ b/refs/reftable-backend.c\n> @@ -251,10 +251,10 @@ static int reftable_ref_iterator_advance(struct ref_iterator *ref_iterator)\n>  \t\tri->base.flags = 0;\n>  \t\tswitch (ri->ref.value_type) {\n>  \t\tcase REFTABLE_REF_VAL1:\n> -\t\t\thashcpy(ri->oid.hash, ri->ref.value.val1);\n> +\t\t\toidread(&ri->oid, ri->ref.value.val1);\n>  \t\t\tbreak;\n>  \t\tcase REFTABLE_REF_VAL2:\n> -\t\t\thashcpy(ri->oid.hash, ri->ref.value.val2.value);\n> +\t\t\toidread(&ri->oid, ri->ref.value.val2.value);\n>  \t\t\tbreak;\n>  \t\tcase REFTABLE_REF_SYMREF: {\n>  \t\t\tint out_flags = 0;\n> @@ -299,7 +299,7 @@ static int reftable_ref_iterator_peel(struct ref_iterator *ref_iterator,\n>  \tstruct git_reftable_iterator *ri =\n>  \t\t(struct git_reftable_iterator *)ref_iterator;\n>  \tif (ri->ref.value_type == REFTABLE_REF_VAL2) {\n> -\t\thashcpy(peeled->hash, ri->ref.value.val2.target_value);\n> +\t\toidread(peeled, ri->ref.value.val2.target_value);\n>  \t\treturn 0;\n>  \t}\n>\n> @@ -977,7 +977,7 @@ git_reftable_reflog_ref_iterator_advance(struct ref_iterator *ref_iterator)\n>\n>  \t\tfree(ri->last_name);\n>  \t\tri->last_name = xstrdup(ri->log.refname);\n> -\t\thashcpy(ri->oid.hash, ri->log.update.new_hash);\n> +\t\toidread(&ri->oid, ri->log.update.new_hash);\n>  \t\treturn ITER_OK;\n>  \t}\n>  }\n> @@ -1090,8 +1090,8 @@ static int git_reftable_for_each_reflog_ent_newest_first(\n>  \t\t\tbreak;\n>  \t\t}\n>\n> -\t\thashcpy(old_oid.hash, log.update.old_hash);\n> -\t\thashcpy(new_oid.hash, log.update.new_hash);\n> +\t\toidread(&old_oid, log.update.old_hash);\n> +\t\toidread(&new_oid, log.update.new_hash);\n>\n>  \t\tfull_committer = fmt_ident(log.update.name, log.update.email,\n>  \t\t\t\t\t   WANT_COMMITTER_IDENT,\n> @@ -1157,8 +1157,8 @@ static int git_reftable_for_each_reflog_ent_oldest_first(\n>  \t\tstruct object_id new_oid;\n>  \t\tconst char *full_committer = \"\";\n>\n> -\t\thashcpy(old_oid.hash, log->update.old_hash);\n> -\t\thashcpy(new_oid.hash, log->update.new_hash);\n> +\t\toidread(&old_oid, log->update.old_hash);\n> +\t\toidread(&new_oid, log->update.new_hash);\n>\n>  \t\tfull_committer = fmt_ident(log->update.name, log->update.email,\n>  \t\t\t\t\t   WANT_COMMITTER_IDENT, NULL,\n> @@ -1330,8 +1330,8 @@ git_reftable_reflog_expire(struct ref_store *ref_store, const char *refname,\n>  \t\tif (err > 0 || strcmp(log.refname, refname)) {\n>  \t\t\tbreak;\n>  \t\t}\n> -\t\thashcpy(ooid.hash, log.update.old_hash);\n> -\t\thashcpy(noid.hash, log.update.new_hash);\n> +\t\toidread(&ooid, log.update.old_hash);\n> +\t\toidread(&noid, log.update.new_hash);\n>\n>  \t\tif (should_prune_fn(&ooid, &noid, log.update.email,\n>  \t\t\t\t    (timestamp_t)log.update.time,\n> @@ -1410,7 +1410,7 @@ static int git_reftable_read_raw_ref(struct ref_store *ref_store,\n>  \t\tstrbuf_addstr(referent, ref.value.symref);\n>  \t\t*type |= REF_ISSYMREF;\n>  \t} else if (reftable_ref_record_val1(&ref) != NULL) {\n> -\t\thashcpy(oid->hash, reftable_ref_record_val1(&ref));\n> +\t\toidread(oid, reftable_ref_record_val1(&ref));\n>  \t} else {\n>  \t\t*type |= REF_ISBROKEN;\n>  \t\terrno = EINVAL;\n>\n>\n> Patrick\n"},{"id":"421989","messageId":"xmqqv98own1s.fsf@gitster.g","threadId":"55491","inReplyTo":"xmqqeefcy35i.fsf@gitster.g","subject":"Re: What's cooking (draft for #4's issue this month)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-04-14T21:53:19Z","receivedAt":"2021-04-14T21:53:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n>> The following patch fixes this, which\n>> I'll include in my next reroll of this series.\n\nHmph, I am not sure if that is wise.  The offending \"-1 no longer is\naccepted\" comes from a topic that is not even in 'next', so you may\nnot want to depend on it.\n\nIt turns out that the two-argument form that passes -1 to the\nfunction we see below as the preimage in your fix-up patch comes\nfrom my conflict resolution.  Your original has\n\n\ttype_from_string_gently(v0, -1, 1);\n\nand the other topic wants to make two unrelated changes to the API,\ni.e. making -1 no longer a valid \"please count, as it is pointless\nto force callers to always count\" option, and drops \"is this asking\nto be gentle?\" parameter.  It may be better to just update what is\nrecorded in my conflict resolution machinery, without making it\n\n\ttype_from_string_gently(v0, strlen(v0), 1);\n\nas it would be necessary to adjust when both topics are merged\nanyway.\n"},{"id":"421992","messageId":"xmqqim4owixg.fsf@gitster.g","threadId":"55491","inReplyTo":"xmqqmtu1zn3o.fsf@gitster.g","subject":"What's cooking (draft for #4's issue this month)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-04-14T23:22:19Z","receivedAt":"2021-04-14T23:22:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here is the (local) test status near the tip of 'seen', relative to\nthe integration result last night.\n\n * hn/reftable has a preparatory change to use oidread() instead of\n   hashcpy() in places queued at its tip.  This is essentially a\n   no-op in the codebase without bc/hash-transition-interop-part-1\n   and would be a bugfix with that topic.  Please squash it into an\n   appropriate step in the series when updating the topic in the\n   future.\n\n * ab/unexpected-object-type topic has an assertion to catch\n   semantic conflicts with topics in-flight queued at its tip.  It\n   would probably be safe to carry it until the topioc is merged to\n   'master' and then remove it after the dust settles.  Please\n   squash it into an appropriate step in the series when updating\n   the topic in the future.\n\n * The tip of 'seen' passes all the tests locally, except that t5540\n   fails when compiled with CC=clang (http-push exits with signal\n   11).  bc/hash-transition-interop-part-1, which is at the tip of\n   'seen', seems to have this issue standalone.  FYI, here is what\n   \"clang --version\" gives me:\n\n    Debian clang version 11.0.1-2\n    Target: x86_64-pc-linux-gnu\n    Thread model: posix\n    InstalledDir: /usr/bin\n\nCredits for the corrections cited above goes to Patrick.\n\nThe attached is a summary of various topics.  Their status may be a\nbit stale (I haven't re-reviewed them with respect to the latest\ndiscussion on the list).\n\nThanks.\n\n----- >8 ---------- >8 ---------- >8 ---------- >8 ---------- >8 -----\n\nExpecting a (hopefully final) reroll.\n - ag/merge-strategies-in-c                                     03-17         #15\n\nExpecting a reroll.\n - sg/bugreport-fixes                                           04-08          #1\n - ds/maintenance-prefetch-fix                                  04-10          #3\n - ma/t0091-bugreport-fix                                       04-12          #1\n\nOn hold, waiting for the \"protections\" topic to stablize.\n + ds/sparse-index                                              03-30/04-07   #21\n\nOn hold.  Probably needs either a reroll or incremental refinements.\n + dl/complete-stash                                            03-24/03-24    #3\n\nStalled\n - es/config-hooks                                              03-10         #36\n - ab/describe-tests-fix                                        04-12          #5\n - ab/pickaxe-pcre2                                             04-12         #22\n - ab/unexpected-object-type                                    04-14         #11\n\nUndecided\n - mt/add-rm-in-sparse-checkout                                 04-08          #7\n - jh/rfc-builtin-fsmonitor                                     04-08         #23\n - mt/parallel-checkout-part-2                                  04-08          #5\n - bc/hash-transition-interop-part-1                            04-10         #16\n - mr/bisect-in-c-4                                             04-11          #4\n - ps/rev-list-object-type-filter                               04-12          #8\n - ab/fsck-unexpected-type                                      04-13          #6\n - rs/repack-without-loosening-promised-objects                 04-14          #2\n - ds/sparse-index-protections                                  04-14         #26\n\nWaiting for reroll.\n - ah/plugleaks                                                 04-10          #9\n\nWaiting for reviews to conclude.\n - ab/doc-lint                                                  04-10          #7\n - ab/rebase-no-reschedule-failed-exec                          04-10          #2\n - hn/refs-trace-errno                                          04-12          #1\n\nWaiting for reviews.\n - jt/push-negotiation                                          04-08          #6\n - tb/multi-pack-bitmaps                                        04-10         #23\n - ab/svn-tests-set-e-fix                                       04-12          #2\n - ab/test-lib-updates                                          04-12         #16\n - ao/p4-avoid-decoding                                         04-12          #2\n - zh/trailer-cmd                                               04-12          #2\n - hn/reftable                                                  04-14         #21\n\nWill merge to 'master'.\n + en/ort-perf-batch-10                                         03-18/04-07    #8\n + en/ort-readiness                                             03-20/04-08   #13\n + jz/apply-run-3way-first                                      04-06/04-08    #1\n + ab/complete-cherry-pick-head                                 04-07/04-09    #1\n + jz/apply-3way-cached                                         04-07/04-09    #1\n + ab/userdiff-tests                                            04-08/04-13    #9\n + ar/userdiff-scheme                                           04-08/04-13    #1\n + ah/merge-ort-ubsan-fix                                       04-12/04-13    #1\n + hn/reftable-tables-doc-update                                04-12/04-13    #1\n + jk/pack-objects-bitmap-progress-fix                          04-12/04-13    #1\n\nWill merge to 'next'.\n - jt/fetch-pack-request-fix                                    04-08          #1\n - ab/detox-gettext-tests                                       04-13          #1\n - ab/usage-error-docs                                          04-13          #3\n - jk/promisor-optim                                            04-13          #3\n - so/log-diff-merge                                            04-13          #5\n - ps/config-global-override                                    04-13          #3\n"},{"id":"421993","messageId":"xmqqeefcwiqz.fsf@gitster.g","threadId":"55491","inReplyTo":"xmqqim4owixg.fsf@gitster.g","subject":"Re: What's cooking (draft for #4's issue this month)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-04-14T23:26:12Z","receivedAt":"2021-04-14T23:26:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n>  * The tip of 'seen' passes all the tests locally, except that t5540\n>    fails when compiled with CC=clang (http-push exits with signal\n>    11).  bc/hash-transition-interop-part-1, which is at the tip of\n>    'seen', seems to have this issue standalone.\n\nBTW https://github.com/git/git/runs/2347905320?check_suite_focus=true#step:5:203\nshows this.\n"},{"id":"421997","messageId":"YHeKFILFySGRo2Dc@camp.crustytoothpaste.net","threadId":"55491","inReplyTo":"xmqqim4owixg.fsf@gitster.g","subject":"Re: What's cooking (draft for #4's issue this month)","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-04-15T00:34:28Z","receivedAt":"2021-04-15T00:35:06Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-04-14 at 23:22:19, Junio C Hamano wrote:\n> Here is the (local) test status near the tip of 'seen', relative to\n> the integration result last night.\n> \n>  * hn/reftable has a preparatory change to use oidread() instead of\n>    hashcpy() in places queued at its tip.  This is essentially a\n>    no-op in the codebase without bc/hash-transition-interop-part-1\n>    and would be a bugfix with that topic.  Please squash it into an\n>    appropriate step in the series when updating the topic in the\n>    future.\n> \n>  * ab/unexpected-object-type topic has an assertion to catch\n>    semantic conflicts with topics in-flight queued at its tip.  It\n>    would probably be safe to carry it until the topioc is merged to\n>    'master' and then remove it after the dust settles.  Please\n>    squash it into an appropriate step in the series when updating\n>    the topic in the future.\n> \n>  * The tip of 'seen' passes all the tests locally, except that t5540\n>    fails when compiled with CC=clang (http-push exits with signal\n>    11).  bc/hash-transition-interop-part-1, which is at the tip of\n>    'seen', seems to have this issue standalone.  FYI, here is what\n>    \"clang --version\" gives me:\n> \n>     Debian clang version 11.0.1-2\n>     Target: x86_64-pc-linux-gnu\n>     Thread model: posix\n>     InstalledDir: /usr/bin\n\nYou should expect a reroll, so feel free to drop this if it breaks\nthings for now and I'll figure out where things are going wrong.\n-- \nbrian m. carlson (he/him or they/them)\nHouston, Texas, US\n"},{"id":"422003","messageId":"xmqqr1jcrr3c.fsf@gitster.g","threadId":"55491","inReplyTo":"YHeKFILFySGRo2Dc@camp.crustytoothpaste.net","subject":"Re: What's cooking (draft for #4's issue this month)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-04-15T06:37:11Z","receivedAt":"2021-04-15T06:37:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" <sandals@crustytoothpaste.net> writes:\n\n> On 2021-04-14 at 23:22:19, Junio C Hamano wrote:\n>> Here is the (local) test status near the tip of 'seen', relative to\n>> the integration result last night.\n>> \n>>  * hn/reftable has a preparatory change to use oidread() instead of\n>>    hashcpy() in places queued at its tip.  This is essentially a\n>>    no-op in the codebase without bc/hash-transition-interop-part-1\n>>    and would be a bugfix with that topic.  Please squash it into an\n>>    appropriate step in the series when updating the topic in the\n>>    future.\n>> \n>>  * ab/unexpected-object-type topic has an assertion to catch\n>>    semantic conflicts with topics in-flight queued at its tip.  It\n>>    would probably be safe to carry it until the topioc is merged to\n>>    'master' and then remove it after the dust settles.  Please\n>>    squash it into an appropriate step in the series when updating\n>>    the topic in the future.\n>> \n>>  * The tip of 'seen' passes all the tests locally, except that t5540\n>>    fails when compiled with CC=clang (http-push exits with signal\n>>    11).  bc/hash-transition-interop-part-1, which is at the tip of\n>>    'seen', seems to have this issue standalone.  FYI, here is what\n>>    \"clang --version\" gives me:\n>> \n>>     Debian clang version 11.0.1-2\n>>     Target: x86_64-pc-linux-gnu\n>>     Thread model: posix\n>>     InstalledDir: /usr/bin\n>\n> You should expect a reroll, so feel free to drop this if it breaks\n> things for now and I'll figure out where things are going wrong.\n\nI actually do appreciate the topic to be in 'seen', as these\nintegration exercises tend to serve as an early warning for\nimpending messy conflicts I'll need to be worried about.\n\nI do worry about the memory requirement bloat of the object_id\nstructure, as we do need to keep one instance per object in-core,\nbut the squashable fix for the reftable topic given by Patrick\nto replace use of hashcpy() with oidread() is still a good idea even\nif we are going to use a different mechanism to keep track of which\nobject_id instance uses what hash algorithm, so again I am happy to\nhave seen your bc/hash-transition-interop-part-1 topic and had an\nearly chance to make it collide with others ;-)\n\nThanks.\n"},{"id":"422017","messageId":"YHgJdtF4X2LQCuZ0@coredump.intra.peff.net","threadId":"55491","inReplyTo":"xmqqv98own1s.fsf@gitster.g","subject":"Re: What's cooking (draft for #4's issue this month)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-04-15T09:37:58Z","receivedAt":"2021-04-15T09:38:01Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Apr 14, 2021 at 02:53:19PM -0700, Junio C Hamano wrote:\n\n> Junio C Hamano <gitster@pobox.com> writes:\n> \n> >> The following patch fixes this, which\n> >> I'll include in my next reroll of this series.\n> \n> Hmph, I am not sure if that is wise.  The offending \"-1 no longer is\n> accepted\" comes from a topic that is not even in 'next', so you may\n> not want to depend on it.\n> \n> It turns out that the two-argument form that passes -1 to the\n> function we see below as the preimage in your fix-up patch comes\n> from my conflict resolution.  Your original has\n> \n> \ttype_from_string_gently(v0, -1, 1);\n> \n> and the other topic wants to make two unrelated changes to the API,\n> i.e. making -1 no longer a valid \"please count, as it is pointless\n> to force callers to always count\" option, and drops \"is this asking\n> to be gentle?\" parameter.  It may be better to just update what is\n> recorded in my conflict resolution machinery, without making it\n> \n> \ttype_from_string_gently(v0, strlen(v0), 1);\n> \n> as it would be necessary to adjust when both topics are merged\n> anyway.\n\nHeh. I wonder if I was too optimistic in my review at:\n\n  https://lore.kernel.org/git/YHCYfeRsHU34ZF%2Fl@coredump.intra.peff.net/\n\n-Peff\n"},{"id":"422029","messageId":"CAFQ2z_OGmvywrxrMQ46avOY9vTK3dHh88Dsfw0Sd9uX5vvSm3w@mail.gmail.com","threadId":"55491","inReplyTo":"xmqqim4owixg.fsf@gitster.g","subject":"Re: What's cooking (draft for #4's issue this month)","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@google.com","sentAt":"2021-04-15T12:58:14Z","receivedAt":"2021-04-15T12:58:28Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"On Thu, Apr 15, 2021 at 1:22 AM Junio C Hamano <gitster@pobox.com> wrote:\n>  * hn/reftable has a preparatory change to use oidread() instead of\n>    hashcpy() in places queued at its tip.  This is essentially a\n>    no-op in the codebase without bc/hash-transition-interop-part-1\n>    and would be a bugfix with that topic.  Please squash it into an\n>    appropriate step in the series when updating the topic in the\n>    future.\n\nDone. Thanks for the fix.\n\n-- \nHan-Wen Nienhuys - Google Munich\nI work 80%. Don't expect answers from me on Fridays.\n--\n\nGoogle Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich\n\nRegistergericht und -nummer: Hamburg, HRB 86891\n\nSitz der Gesellschaft: Hamburg\n\nGeschäftsführer: Paul Manicle, Halimah DeLaine Prado\n"},{"id":"422042","messageId":"xmqq4kg7s9y8.fsf@gitster.g","threadId":"55491","inReplyTo":"YHgJdtF4X2LQCuZ0@coredump.intra.peff.net","subject":"Re: What's cooking (draft for #4's issue this month)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-04-15T18:02:07Z","receivedAt":"2021-04-15T18:02:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> Heh. I wonder if I was too optimistic in my review at:\n>\n>   https://lore.kernel.org/git/YHCYfeRsHU34ZF%2Fl@coredump.intra.peff.net/\n\nYes, merging is hard.  When merging a topic X into 'seen', I can\nreview \"log -p ..MERGE_HEAD\" and keep the core changes the topic\nwants to do in my head while reviewing the conflicting parts, but\nthis is the other \"log -p MERGE_HEAD..\" direction where all the\nlittle cuts _other_ topics inflicted on the codebase before an\nattempted merge, and something seemingly benign and well intended\nchange like \"well nobody passes -1 to ask us to count _now_, so\nlet's drop the feature without even bothering to check nobody does\nso in the future\" can easily be missed.\n"},{"id":"422226","messageId":"YHzmjhLy2QjDefXy@camp.crustytoothpaste.net","threadId":"55491","inReplyTo":"xmqqr1jcrr3c.fsf@gitster.g","subject":"Re: What's cooking (draft for #4's issue this month)","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-04-19T02:10:22Z","receivedAt":"2021-04-19T02:11:00Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-04-15 at 06:37:11, Junio C Hamano wrote:\n> I actually do appreciate the topic to be in 'seen', as these\n> integration exercises tend to serve as an early warning for\n> impending messy conflicts I'll need to be worried about.\n> \n> I do worry about the memory requirement bloat of the object_id\n> structure, as we do need to keep one instance per object in-core,\n> but the squashable fix for the reftable topic given by Patrick\n> to replace use of hashcpy() with oidread() is still a good idea even\n> if we are going to use a different mechanism to keep track of which\n> object_id instance uses what hash algorithm, so again I am happy to\n> have seen your bc/hash-transition-interop-part-1 topic and had an\n> early chance to make it collide with others ;-)\n\nI'm still working on a full reroll for the series including performance\nmeasurements (since this took me much longer than I expected it would),\nbut I wanted to include a patch for the segfault below to keep things\ntidy in the mean time.  I should point out that this doesn't appear to\ncrash when running the testsuite in SHA-256 mode for reasons I'm not\nsure about, which explains why I didn't see it originally.\n\n---- %< ----\nFrom 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001\nFrom: \"brian m. carlson\" <sandals@crustytoothpaste.net>\nDate: Sun, 18 Apr 2021 22:56:04 +0000\nSubject: [PATCH] http-push: set algorithm when reading object ID\n\nIn most places in the codebase, we use oidread to properly read an\nobject ID into a struct object_id.  However, in the HTTP code, we end up\nneeding to parse a loose object path with a slash in it, so we can't do\nthat.  Let's instead explicitly set the algorithm in this function so we\ncan rely on it in the future.\n\nSigned-off-by: brian m. carlson <sandals@crustytoothpaste.net>\n---\n http-push.c | 2 ++\n 1 file changed, 2 insertions(+)\n\ndiff --git a/http-push.c b/http-push.c\nindex b60d5fcc85..5675cd7708 100644\n--- a/http-push.c\n+++ b/http-push.c\n@@ -1022,6 +1022,8 @@ static void remote_ls(const char *path, int flags,\n /* extract hex from sharded \"xx/x{38}\" filename */\n static int get_oid_hex_from_objpath(const char *path, struct object_id *oid)\n {\n+\toid->algo = hash_algo_by_ptr(the_hash_algo);\n+\n \tif (strlen(path) != the_hash_algo->hexsz + 1)\n \t\treturn -1;\n \n---- %< ----\n-- \nbrian m. carlson (he/him or they/them)\nHouston, Texas, US\n"},{"id":"422354","messageId":"xmqq5z0h989v.fsf@gitster.g","threadId":"55491","inReplyTo":"YHzmjhLy2QjDefXy@camp.crustytoothpaste.net","subject":"Re: What's cooking (draft for #4's issue this month)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-04-19T23:14:36Z","receivedAt":"2021-04-19T23:14:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" <sandals@crustytoothpaste.net> writes:\n\n> I'm still working on a full reroll for the series including performance\n> measurements (since this took me much longer than I expected it would),\n> but I wanted to include a patch for the segfault below to keep things\n> tidy in the mean time.  I should point out that this doesn't appear to\n> crash when running the testsuite in SHA-256 mode for reasons I'm not\n> sure about, which explains why I didn't see it originally.\n\nThanks; will apply and keep it with the latest round for now.  \n\n>\n> ---- %< ----\n> From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001\n> From: \"brian m. carlson\" <sandals@crustytoothpaste.net>\n> Date: Sun, 18 Apr 2021 22:56:04 +0000\n> Subject: [PATCH] http-push: set algorithm when reading object ID\n>\n> In most places in the codebase, we use oidread to properly read an\n> object ID into a struct object_id.  However, in the HTTP code, we end up\n> needing to parse a loose object path with a slash in it, so we can't do\n> that.  Let's instead explicitly set the algorithm in this function so we\n> can rely on it in the future.\n>\n> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>\n> ---\n>  http-push.c | 2 ++\n>  1 file changed, 2 insertions(+)\n>\n> diff --git a/http-push.c b/http-push.c\n> index b60d5fcc85..5675cd7708 100644\n> --- a/http-push.c\n> +++ b/http-push.c\n> @@ -1022,6 +1022,8 @@ static void remote_ls(const char *path, int flags,\n>  /* extract hex from sharded \"xx/x{38}\" filename */\n>  static int get_oid_hex_from_objpath(const char *path, struct object_id *oid)\n>  {\n> +\toid->algo = hash_algo_by_ptr(the_hash_algo);\n> +\n>  \tif (strlen(path) != the_hash_algo->hexsz + 1)\n>  \t\treturn -1;\n>  \n> ---- %< ----\n"}]}