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: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-2.9 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by dcvr.yhbt.net (Postfix) with ESMTP id 9C1F91F910 for ; Sat, 19 Nov 2022 01:38:05 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="TMIG61rQ"; dkim-atps=neutral Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232291AbiKSBiB (ORCPT ); Fri, 18 Nov 2022 20:38:01 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40870 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232651AbiKSBhq (ORCPT ); Fri, 18 Nov 2022 20:37:46 -0500 Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 41C75173553 for ; Fri, 18 Nov 2022 16:41:40 -0800 (PST) Received: by mail-lf1-x12d.google.com with SMTP id a29so10749160lfj.9 for ; Fri, 18 Nov 2022 16:41:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=pA/mS/L9kd9zz4Dwtp4ScR+7JLb27S7zu562nBEvBwI=; b=TMIG61rQE0/zBYNsCoxYWs17WsrDhxaS3OFcKVVW7v0gw137cXGc1UQjl0E5xqOS10 NWDXXiusxOowMFLDa4lsZbikiHRKBTXQapm8TjjCYKw9n1PVZf1+ceXX5vJAqdQNhyPR EswqKgXYGEU9OCAdPUeMz9WGe4nAhYv41/NJ+kN+FzmV+hlE2fQbNWzBsaF/husk1PoL ClkBYuLQCExexMNYNqGONuuGgLgCmu6vNcsYPUQx0IlpMKO1Ox6utktYvmNABwM1H3Jm k1Jqe5SqMXEsOTgXxSfWwuH8uZ/QbkJpErmfc6dcMews/AGFjkgr2tvKJnegJ2j/GG3r WwLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=pA/mS/L9kd9zz4Dwtp4ScR+7JLb27S7zu562nBEvBwI=; b=p16E+0TjTo0xyAAhk/LvCLNzoxbOYP4G8jkwnhuHYbn9tN6Ufocwukez370XPvkt11 Zj0dnedT/M94kTICJUMleBLmKBXwsbFbrnyUNKLtMawaPSi2dteYQqBWxKSFfXd8gDu1 D6pBN25Wb1+A8geFJtx7tqNidrCZGof0tsfThGvV0Ao2DqNC18W19WClJSGutEAEmsNz YcIz3Di0KDjQ8geU0XGUOzBrD8/ZdKrDvvRwxJ3wcs09XWI1wuW6P0XDtvSiNx/NKJm0 TU4nLKLD7BA8k1YiYOLSeBrM1TCFx6R6PSSvZQkeW+chwF/JsQfsSMjjr0IxRcFLaK92 67lA== X-Gm-Message-State: ANoB5plQPmRHDKssALPPGCcVaf4VKHNDiHzI5aA/gk7sKIo2DcjEHkUo LgCnoQUDn5MZFRXhLpwUxq9HKqJ81QCZJnqYvaZMGwT2 X-Google-Smtp-Source: AA0mqf4YE+EcuzUN9uQMiDmgst6mM6iAQt58YgoakzpWXM+BIMmiN/X62ZOUVsZFfW9WNype5U89J59xPL88wd/NvXU= X-Received: by 2002:a05:6512:280e:b0:4a2:5154:ead9 with SMTP id cf14-20020a056512280e00b004a25154ead9mr3297054lfb.32.1668818498210; Fri, 18 Nov 2022 16:41:38 -0800 (PST) MIME-Version: 1.0 References: <0e156172-0670-2832-78cb-c7dfe2599192@github.com> In-Reply-To: From: Elijah Newren Date: Fri, 18 Nov 2022 16:41:25 -0800 Message-ID: Subject: Re: [PATCH 00/30] [RFC] extensions.refFormat and packed-refs v2 file format To: Junio C Hamano Cc: Derrick Stolee , Derrick Stolee via GitGitGadget , git@vger.kernel.org, jrnieder@gmail.com Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Fri, Nov 18, 2022 at 3:31 PM Junio C Hamano wrote: > > Derrick Stolee writes: > > > On 11/11/22 6:28 PM, Elijah Newren wrote: > >> On Mon, Nov 7, 2022 at 11:01 AM Derrick Stolee via GitGitGadget > >> wrote: > I have been and am still offline and haven't examined this proposal > in detail, but would it be a better longer-term approach to improve > reftable backend, instead of piling more effort on loose+packed > filesystem based backend? Well, Stolee explicitly brought this up multiple times in his cover letter with various arguments about why he thinks this approach is a better way to move us on the path towards improved ref handling, and doesn't see it as excluding the reftable option but just opening us up to more incremental (and incrementally testable) improvements. This question came up early and often in the cover letter; he even ends with a "Relationship to reftable" section. But he is clearly open to feedback about whether others agree or disagree with his thesis. (I haven't looked much at reftable, so I can't opine on that question, but Stolee's approach did seem eminently easier to review. I did have some questions about his proposal(s) because I didn't quite understand them, in part due to being unfamiliar with the area.)