From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS53758 23.128.96.0/24 X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by dcvr.yhbt.net (Postfix) with ESMTP id 46EE91F8C6 for ; Mon, 13 Sep 2021 19:58:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347651AbhIMT73 (ORCPT ); Mon, 13 Sep 2021 15:59:29 -0400 Received: from pb-smtp1.pobox.com ([64.147.108.70]:58452 "EHLO pb-smtp1.pobox.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238454AbhIMT73 (ORCPT ); Mon, 13 Sep 2021 15:59:29 -0400 Received: from pb-smtp1.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 942FDD54AF; Mon, 13 Sep 2021 15:58:12 -0400 (EDT) (envelope-from junio@pobox.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:message-id:mime-version:content-type; s=sasl; bh=yBhJNilObH27ER7RYzYy+/sSED+x8+o7xDt8VxQiWf0=; b=fnKX Xt+PUsDAm3x7C0O4Y/zUkS9dVT75wEoC0DqqcGskv/MZPAa/7aHD925u2BS9NYfE UCqW2sQYwZonJxcTyZ9JjG9B1Gtck7iiunX9/TcIyoOIE+YLCf66dv81ojYND0Mf 7sV/anXTvsVVbnTaEd0taC5VjtAqWAvJB5mhGcU= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 8AD12D54AE; Mon, 13 Sep 2021 15:58:12 -0400 (EDT) (envelope-from junio@pobox.com) Received: from pobox.com (unknown [104.196.172.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 12632D54AC; Mon, 13 Sep 2021 15:58:12 -0400 (EDT) (envelope-from junio@pobox.com) From: Junio C Hamano To: Jeff King Cc: Johannes Schindelin , =?utf-8?Q?Ren=C3=A9?= Scharfe , Taylor Blau , Git List Subject: Re: [PATCH] merge-recursive: use fspathcmp() in path_hashmap_cmp() References: <512abaef-d71c-9308-6a62-f37b4de69e60@web.de> <8d2e0876-9441-9665-ebb1-8cb28902014b@web.de> <8bd13e99-208b-4c22-90e6-28227593e9c4@web.de> Date: Mon, 13 Sep 2021 12:58:11 -0700 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Pobox-Relay-ID: ECD52224-14CC-11EC-BEA9-62A2C8D8090B-77302942!pb-smtp1.pobox.com Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Jeff King writes: > Another approach is to stuff the appropriate globals into the repository > struct, and then "push" onto the global the_repository pointer, treating > it like a stack. And then low-level code is free to use that global > context, even if it wasn't passed in. > ... > - it's a challenge with threading (an obvious problem would be a > multi-threaded grep which wanted to descend into a submodule). Using > a thread-local global for the_repository might solve that. > > It's possible that this is a terrible direction to go, so I'm not > necessarily endorsing it, but just offering it as a possibility to think > about. The trickiest thing is that any devil would likely be in the > details, and we wouldn't know until proceeding for a while along that > path. Whereas passing around a context struct, while verbose and > annoying, is a well-understood construct. I agree that it is cute, thread-unsafe, and tricky. Let's leave it at an interesting thought experiment for now. Thanks.