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=-4.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,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 8C3101F531 for ; Mon, 10 Aug 2020 16:04:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727088AbgHJQEG (ORCPT ); Mon, 10 Aug 2020 12:04:06 -0400 Received: from pb-smtp2.pobox.com ([64.147.108.71]:59784 "EHLO pb-smtp2.pobox.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726338AbgHJQEG (ORCPT ); Mon, 10 Aug 2020 12:04:06 -0400 Received: from pb-smtp2.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id E6D40856AB; Mon, 10 Aug 2020 12:04:03 -0400 (EDT) (envelope-from junio@pobox.com) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=PBqiRLhv3sF6CFGd7a1OIQpaxxw=; b=n2cEYj eFvfG1MZybJC4po2mqWl7MwwbDPekXL7XgsSwx36nIp6seD3Kieg718pBesrkeFj TGTV5m78Ehb+zah+zgd+l7ZtfLIpi3pNtNoGV5QsPhTrYs0W7Jf02JpuSmKGx3ve FkGoDFWbKR+pzrEXVnCWhEJXh20A1EIINNydw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; q=dns; s=sasl; b=v/caf7byeyBVDsT0JiEDPwpW6QolCFh6 LmumVLEEpXYKrlxTAWF+NeJ95hco1Lm+9k1loL6+z+tx1SpH13T521NFucIoD+UE eh8rMNoRPzvkM1kg7kGa1NwQppUjIuq+WdC5o15D+Zrk9BZY0BfDZ5P/IxfWkUMU mfEo2tQ7aUU= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id DBFF9856AA; Mon, 10 Aug 2020 12:04:03 -0400 (EDT) (envelope-from junio@pobox.com) Received: from pobox.com (unknown [35.196.173.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 5616C856A9; Mon, 10 Aug 2020 12:04:03 -0400 (EDT) (envelope-from junio@pobox.com) From: Junio C Hamano To: Han-Wen Nienhuys Cc: Han-Wen Nienhuys via GitGitGadget , git , Han-Wen Nienhuys Subject: Re: [PATCH v3 0/3] Remove special casing for PSEUDOREF updates References: Date: Mon, 10 Aug 2020 09:04:02 -0700 In-Reply-To: (Han-Wen Nienhuys's message of "Mon, 10 Aug 2020 16:27:08 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Pobox-Relay-ID: 1C52059C-DB23-11EA-B608-2F5D23BA3BAF-77302942!pb-smtp2.pobox.com Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org 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. 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, that anybody who tries to write FETCH_HEAD using the ref API gets an error, and letting the writers write into it directly?