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-Status: No, score=-11.5 required=3.0 tests=AWL,BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_PASS,SPF_PASS,USER_IN_DEF_DKIM_WL 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 3DB4B1F66E for ; Tue, 11 Aug 2020 10:50:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728463AbgHKKuO (ORCPT ); Tue, 11 Aug 2020 06:50:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45298 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728280AbgHKKuM (ORCPT ); Tue, 11 Aug 2020 06:50:12 -0400 Received: from mail-ua1-x943.google.com (mail-ua1-x943.google.com [IPv6:2607:f8b0:4864:20::943]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4F582C06174A for ; Tue, 11 Aug 2020 03:50:12 -0700 (PDT) Received: by mail-ua1-x943.google.com with SMTP id g20so3353600uan.7 for ; Tue, 11 Aug 2020 03:50:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=w7MYwNDfAcFWIwaZpb1ZWyEDlxaM58fymy/kgpEi1KQ=; b=GP+micLz7gHA0/d7MalGNiXXIxHHVdj6JRdwzt7F9XocXoLBGJMCiAfW0XfSvjo6zO 05k/pqgUmqGYjokcPYo2yXNo0NKH/Z++SFWXMfSyHfm10RBRFoVO2HwHeDa3ws4B627c hvOxh+9a1sNm+nRcxL86whG1wA3ZVHzDhgnR+l6y/6h3jrqocBu3m4HiVfMYRjlXKnqX GrIJCxWD2PDSfGbLhp6P4d/NDnuIXdszKEPrWU8zsN0PQEK9LzzvnHw642Ke0CSQTy96 xZ/fDUX4b3fqymJqatXf6SO3fQCTjjqmiHTWlDWiWbUjLf27L7Q+k0BoEK+9v9y+bf84 Q/cA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=w7MYwNDfAcFWIwaZpb1ZWyEDlxaM58fymy/kgpEi1KQ=; b=TOgSZWJh1qSnBwBCNJy8DasB+GKrYM3ithYDxZLN/gtJ+GXmwOTwL+HjVIcziOy3Tn BeobBid9GLb+g69n3b29v54V7FtMzNFAXw9AvDX63oRhxLLFVqCiNYrDIhUTM9IJH6si 93q5GYrhOV/aRCfgBRcriD+x5N3zTLd0QeGKEqj5H4ntQ2S2egeA697fTM0sLMM/Ugds X+klIqlIkaJJWV+VeO+eoM9ibQCWPh6SH5uHNWLKSeuGxTG7snRjLZseY1BcEvakaDWs XkbhditUxxYs1Hgutt7ZOf2oCehfzCGNPX+TSlBUF/hOuhX4qV/0NFBHjauofCqOEVWi c5Og== X-Gm-Message-State: AOAM531NMKZGLsEJfGnzJscShl/nCR91KKAeX+Zx6GYZd0SaW+srSSc0 RgyVtXgsA7daMMtL10t/TLQnVzIZ2W0aPWYzQK0nKQ== X-Google-Smtp-Source: ABdhPJwqScagxcMMu8jNAFwjQBpxvM7RbTxmkB4HUNb41s+ohtOtYEbDEgI1eHgu3q4W5xWXs3SAkuJeXyM4iaVos3A= X-Received: by 2002:ab0:6054:: with SMTP id o20mr17269734ual.87.1597143011254; Tue, 11 Aug 2020 03:50:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Han-Wen Nienhuys Date: Tue, 11 Aug 2020 12:49:59 +0200 Message-ID: Subject: Re: [PATCH v3 0/3] Remove special casing for PSEUDOREF updates To: Junio C Hamano Cc: Han-Wen Nienhuys via GitGitGadget , git , Han-Wen Nienhuys Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Mon, Aug 10, 2020 at 6:04 PM Junio C Hamano wrote: > > Han-Wen Nienhuys writes: > > > Dealing with FETCH_HEAD generically isn't possible unless we extend > > the API of the ref backend: the generic ref_store instance doesn't > > offer a way to get at the path that corresponds to FETCH_HEAD, so we > > can't handle it in refs_read_raw_ref(). In the current reftable > > series, FETCH_HEAD is dealt with in the backends separately. > > I am not sure what the best way would be, but I do not think any > existing code writes into it using the refs API at all, even though > it may be read only for the first object name using the refs API. > > And I am not sure if we want to extend the write side API so that > the callers can express the full flexibility of that single file. That's not what I am getting at. I am just interested in how to handle FETCH_HEAD in refs_read_raw_ref. > So perhaps the best way forward would be to ensure that anybody who > tries to read from FETCH_HEAD using the ref API reads the first > object name in it from $GIT_DIR/FETCH_HEAD file as we've always done > since the beginning of time, regardless of what ref backend is used, Right, but how do we get at the value of $GIT_DIR given a struct ref_store? We can either push that out to the ref store backend, because each backend knows what $GIT_DIR is, or we can make $GIT_DIR a property of the generic ref_store. I suppose it's cleaner to make the latter API extension. --=20 Han-Wen Nienhuys - Google Munich I work 80%. Don't expect answers from me on Fridays. -- Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Gesch=C3=A4ftsf=C3=BChrer: Paul Manicle, Halimah DeLaine Prado