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_HI,SPF_HELO_PASS,SPF_PASS, T_SCC_BODY_TEXT_LINE 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 9B0391F852 for ; Tue, 1 Feb 2022 22:13:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237598AbiBAWMB (ORCPT ); Tue, 1 Feb 2022 17:12:01 -0500 Received: from pb-smtp1.pobox.com ([64.147.108.70]:64052 "EHLO pb-smtp1.pobox.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231178AbiBAWMA (ORCPT ); Tue, 1 Feb 2022 17:12:00 -0500 Received: from pb-smtp1.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 2CC5D105417; Tue, 1 Feb 2022 17:12:00 -0500 (EST) (envelope-from junio@pobox.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; s=sasl; bh=2rvjwOkD8sTR LgaWSG9RmzeCnlgpZ4tQWPt8Jd+u91w=; b=El7ADKn2+GZGlhmMNC3AtExeFG7C Wmi3iKPQXj8RMx9FlMbsAlc+zIVrR5uA6cwVuwtLmpxpEuxCQ5cKQe4tTPO7phi/ NMnzlODZK9Vy7r/5KvuyLohYxPcEbqFv7h3nOhBUbOhpCSVa63eoXp/0hXRHyeVI zcWSeZc89V0N8Hc= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 20CAC105415; Tue, 1 Feb 2022 17:12:00 -0500 (EST) (envelope-from junio@pobox.com) Received: from pobox.com (unknown [104.133.2.91]) (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 84416105414; Tue, 1 Feb 2022 17:11:59 -0500 (EST) (envelope-from junio@pobox.com) From: Junio C Hamano To: =?utf-8?B?w4Z2YXIgQXJuZmrDtnLDsA==?= Bjarmason Cc: Han-Wen Nienhuys , Taylor Blau , Han-Wen Nienhuys via GitGitGadget , git@vger.kernel.org, Han-Wen Nienhuys Subject: Re: [PATCH 2/3] t1405: mark test that checks existence as REFFILES References: <1ded69d89709d23147b29f67122b659293414405.1643651420.git.gitgitgadget@gmail.com> <220201.861r0m9t8n.gmgdl@evledraar.gmail.com> Date: Tue, 01 Feb 2022 14:11:58 -0800 In-Reply-To: <220201.861r0m9t8n.gmgdl@evledraar.gmail.com> (=?utf-8?B?IsOG?= =?utf-8?B?dmFyIEFybmZqw7Zyw7A=?= Bjarmason"'s message of "Tue, 01 Feb 2022 22:22:00 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Pobox-Relay-ID: F9D22172-83AB-11EC-BAE2-5E84C8D8090B-77302942!pb-smtp1.pobox.com Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org =C3=86var Arnfj=C3=B6r=C3=B0 Bjarmason writes: > We could surely add magic record types, but how would such a dance be > performed while keeping compatibility with existing JGit clients? Yes. It is exactly the point of the question I asked. If it is simple and easy to add such a new type that is ignored/skipped by existing clients, then we can go that route. If it is simple and easy to add a new bit per ref that existing clients would not barf, we can use that as an alternative implementation strategy. And if neither is possible, and there is no other viable third way, then what I wrote in the part you omitted from your quote still stands, which was: >> It is probably a lot more sensible to fail refs_create_reflog() and >> safe_create_reflog() (which is a thin wrapper around the former), if >> we cannot implement "a reflog can exist and have no entries yet" >> semantics.