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=-6.4 required=3.0 tests=AWL,BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, LIST_MIRROR_RECEIVED,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL shortcircuit=no autolearn=no 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 860FD1F670 for ; Thu, 17 Feb 2022 10:07:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238985AbiBQKHT (ORCPT ); Thu, 17 Feb 2022 05:07:19 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:58312 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231772AbiBQKHS (ORCPT ); Thu, 17 Feb 2022 05:07:18 -0500 Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0722C130828 for ; Thu, 17 Feb 2022 02:07:04 -0800 (PST) Received: by mail-vs1-xe2e.google.com with SMTP id d11so1574854vsm.5 for ; Thu, 17 Feb 2022 02:07:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=sw5RGr9MWRhvFHs0yMBQkO+zOBda+kg/SgCH+4FOnj0=; b=FBDhm9x2KRZ4hWEv3KyXDxOAF+TjK/G/G7qyWP/Bb81UbabbZQxyZXkTxD/rV/LO5F dIhc1i4811YyZH2Ereqi39RRgbLJGK5f7uzbmtQhgS2vCWOnNX4B6ZxpcCLc96VqWA16 uX26S4ikerh24zetaip4nxk6ccqH+oTeIe/UHVPk8iCEj5h7Q2Hwrn+dGcndIHHJoIYm oMJI+uVHo+xYxRivc/2lQCineDVOY7iIlGBHd536Is71bmAWkckuPW04+XkQpb11atbn +EXSjInMstwGmz9gTZClehR9+yn0SC4MpUObps2rhg94+R/vYKOMrQ2nKnCKOkRqpXZX gEog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=sw5RGr9MWRhvFHs0yMBQkO+zOBda+kg/SgCH+4FOnj0=; b=Io7/1XPQvrac79Qm2/seOsyeXyFcRPqkYj7i1UtedIb7YDhzwQRkVb82s3VBZ+gnxM pi+nOpfjCdnEI6YBF4jcyqTwbkGGBY9byYPpjcNRTbef9r24dHYLbnSYq/xvk3dDsehy 9CfHukmNpRJ1SQjGNDvFXiJ/bb0h/KtifFtKRr3/j2MejsAw0GuD6Q1t0t9/8cYy+/E/ EX5nGaPL2pNHQ8XVCHPsNu5S6SeZPRi6asPpXi/tz5MC7HDGMuZ+nhtM8m/R1u/nDyqi s0+4jHsnZRLRWqSr65JoO/oEZYkH11AZ+in/HA2sIvRv5BzcEgoARutDQg21PbJff7U7 RhGQ== X-Gm-Message-State: AOAM530u8kUKKY2FvHCS1rLBbo/XkKF3vRwarwfqNQEd2fuiGIRyvSfw 5pMVHxIrpDzvS1psxdEc5dWrPgrsdLEmgpq5yblZ8xWGZAnFHA== X-Google-Smtp-Source: ABdhPJy5h3Uc7I/lhuKDpm0fEUV/SNVXmFNCCnSoZjISG1W7t0kdVNQ0ESUYIT6Mmd4rmxrnYLIRyH9WALua2phbH0c= X-Received: by 2002:a05:6102:2912:b0:31a:5ab3:f44b with SMTP id cz18-20020a056102291200b0031a5ab3f44bmr960549vsb.53.1645092024100; Thu, 17 Feb 2022 02:00:24 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Han-Wen Nienhuys Date: Thu, 17 Feb 2022 11:00:12 +0100 Message-ID: Subject: Re: [PATCH] glossary: describe "worktree" To: Junio C Hamano Cc: Elijah Newren , Git Mailing List , Derrick Stolee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Thu, Feb 10, 2022 at 8:14 PM Junio C Hamano wrote: > > Han-Wen Nienhuys writes: > > > on a tangent: I posted a patch to write MERGE_AUTOSTASH, > > rebase-merge/autostash, etc. as refs. > > Is that the right direction? They are read like refs, but they are > > together in a directory with other bits of stateful data (similar to > > what is appended to FETCH_HEAD). Perhaps I should rather change the > > read path, so they're always read as files rather than refs? > > I think that would be a lot more preferrable. If a file is written > to record pieces of info, among which an object name happens to be > included, it does not have to be recorded as a ref. Especially if > it is an ephemeral file like MERGE_AUTOSTASH and FETCH_HEAD. For FETCH_HEAD, doing git fetch host refs/changes/23/123/1 && git checkout FETCH_HEAD is the standard idiom for downloading a change from Gerrit. I suspect there might be other similar idioms. This means we have to read them through the refs machinery. I think the most sensible approach is to pass the read/write through refs_* functions, but special-case the storage, so it doesn't go through reftable. We already do this for FETCH_HEAD and MERGE_HEAD in refs_read_raw_refs. This means we need a formal definition of which refs should be treated as files. Maybe we could do as follows: Pseudorefs are 1) all uppercase toplevel names except for HEAD 2) all refs that are not under refs/* (for example: rebase-{merge,apply}/autostash) Pseudorefs are always stored as files containing a hex object_id. Pseudorefs can be read or written through refs_* functions, but given the storage guarantees, it's also valid to read/write them outside refs_* functions It is forbidden to make cross-ref transactions that involve pseudorefs. --=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, Liana Sebastian