Re: What's cooking (draft for #4's issue this month)

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 15, 2021, 06:37 UTC
Message-ID: <xmqqr1jcrr3c.fsf@gitster.g>
In-Reply-To: <YHeKFILFySGRo2Dc@camp.crustytoothpaste.net>

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

Show 31 quoted lines

> On 2021-04-14 at 23:22:19, Junio C Hamano wrote:
>> Here is the (local) test status near the tip of 'seen', relative to
>> the integration result last night.
>> 
>>  * hn/reftable has a preparatory change to use oidread() instead of
>>    hashcpy() in places queued at its tip.  This is essentially a
>>    no-op in the codebase without bc/hash-transition-interop-part-1
>>    and would be a bugfix with that topic.  Please squash it into an
>>    appropriate step in the series when updating the topic in the
>>    future.
>> 
>>  * ab/unexpected-object-type topic has an assertion to catch
>>    semantic conflicts with topics in-flight queued at its tip.  It
>>    would probably be safe to carry it until the topioc is merged to
>>    'master' and then remove it after the dust settles.  Please
>>    squash it into an appropriate step in the series when updating
>>    the topic in the future.
>> 
>>  * The tip of 'seen' passes all the tests locally, except that t5540
>>    fails when compiled with CC=clang (http-push exits with signal
>>    11).  bc/hash-transition-interop-part-1, which is at the tip of
>>    'seen', seems to have this issue standalone.  FYI, here is what
>>    "clang --version" gives me:
>> 
>>     Debian clang version 11.0.1-2
>>     Target: x86_64-pc-linux-gnu
>>     Thread model: posix
>>     InstalledDir: /usr/bin
>
> You should expect a reroll, so feel free to drop this if it breaks
> things for now and I'll figure out where things are going wrong.

I actually do appreciate the topic to be in 'seen', as these integration exercises tend to serve as an early warning for impending messy conflicts I'll need to be worried about.

I do worry about the memory requirement bloat of the object_id structure, as we do need to keep one instance per object in-core, but the squashable fix for the reftable topic given by Patrick to replace use of hashcpy() with oidread() is still a good idea even if we are going to use a different mechanism to keep track of which object_id instance uses what hash algorithm, so again I am happy to have seen your bc/hash-transition-interop-part-1 topic and had an early chance to make it collide with others ;-)

Thanks.