From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-3.1 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.6 Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org [IPv6:2604:1380:45d1:ec00::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 033D01F452 for ; Mon, 30 Oct 2023 17:15:08 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=fwy0GFny; dkim-atps=neutral Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id EB0F71C20A44 for ; Mon, 30 Oct 2023 17:15:06 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id E4C9519471; Mon, 30 Oct 2023 17:15:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="fwy0GFny" Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net [23.128.96.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E711833ED for ; Mon, 30 Oct 2023 17:14:58 +0000 (UTC) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 46CC1AB for ; Mon, 30 Oct 2023 10:14:57 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id 2adb3069b0e04-5082a874098so4600983e87.3 for ; Mon, 30 Oct 2023 10:14:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698686095; x=1699290895; darn=vger.kernel.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=brmV05OaZJHkvbwsDoJvNqj7KKP3jmgcUm50SC1M8pg=; b=fwy0GFnykdOVwWL3CqiVpTWlYCEqif2M2KolM9hT10oKfGEYUdXEFfkqyccj9ivXF8 s+QaINV03og73rrN9m6LhljF4DRpPeaJcrI9LJ/MEynRbIEnnCgq6c1ip1rT+6BjANf0 6gTIKW1KuM8jJPeN5cW5LAseuKQWGxS+bN+ofxf0XQkiDtdDWXi328mH+W1doJUQto7o eJvrkDapSewyToteuVXjkk1857EMZZPqLt1QQov/yCI81bPQyP73uNLdEpwyi6ifB/6D C/UwTdsVkuzs5b+CZY5wlSOrOlgcAPPuZAuJ3I8UgwPueD7oRtlmdRIsAmDQFFstfJxM FlIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698686095; x=1699290895; h=content-transfer-encoding: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=brmV05OaZJHkvbwsDoJvNqj7KKP3jmgcUm50SC1M8pg=; b=q23zJBbQypKuvlztIn0/+Jm+oL0ufGxd+H6Ni0Rz76Z0iwIVVnFVRxZxTXRlDQO3Eg 7KNc2PFOuwib7k24/pjnB+FdhP2Eg6jKdvoDds7abGOlfdq/3iz+jsxFqc3UW6XCgoMq F//5quESxn/J5fhAcb2vkjk9+VipowEYpUaoHiXyOFjbEOb0jIPSsq3QVI1e10KQmTeP F1sgAXlUxzQ7DFk2IxdqztDi5D7bKZvKC6JO+G8y062DxCy6UJ9wUKPwQgvuZcArB4SI 8cT51ONCLl4vqEdbeVIAXmBPu9x3oMMNcC2a90eP/sOwrYTw7agPAmVgfuUZklN1KBJX Byxg== X-Gm-Message-State: AOJu0YwQwvBhK/0UT8PSXkrroDTBtoE/c61Zii0fT8iWekt0+/S57QtL LZgwb8JMC+CeCgyIpi1sdBl8OHrM8alRSnBe3d4= X-Google-Smtp-Source: AGHT+IHBrYI4COWjmRUzc6YGKDyegA2F9RbEAJcpY3j2y5Ug11Tpl/5WdUrpGP7GIWNEWNzaoV9y8setvf4usHQR6jc= X-Received: by 2002:a19:650c:0:b0:507:9996:f62b with SMTP id z12-20020a19650c000000b005079996f62bmr6249931lfb.56.1698686095090; Mon, 30 Oct 2023 10:14:55 -0700 (PDT) Precedence: bulk X-Mailing-List: git@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: , MIME-Version: 1.0 References: <20231024195655.2413191-1-sandals@crustytoothpaste.net> In-Reply-To: From: Elijah Newren Date: Mon, 30 Oct 2023 10:14:42 -0700 Message-ID: Subject: Re: [PATCH 0/1] Object ID support for git merge-file To: "brian m. carlson" , Taylor Blau , Elijah Newren , git@vger.kernel.org, Junio C Hamano , Phillip Wood Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Unsubscribe-Post: List-Unsubscribe=One-Click On Mon, Oct 30, 2023 at 9:24=E2=80=AFAM brian m. carlson wrote: > > On 2023-10-30 at 15:54:14, Taylor Blau wrote: > > On Sat, Oct 28, 2023 at 11:24:06PM -0700, Elijah Newren wrote: > > > But...wouldn't you already have the conflicts generated when doing th= e > > > merge and learning that it fails? Why would you need to generate the= m > > > again? > > > > brian would know better than I do, but I believe the reason is because > > the "attempt this merge" RPC is handled separately from the "show me th= e > > merge conflict(s) at xyz path". Those probably could be combined > > (obviating the need for this patch), but doing so is probably rather > > complicated. > > That's correct. They could in theory happen at different times, which > is why they're not linked. Maybe this is digging a little into "historical reasons" too much, but this still seems a little funny. If they happen at different times, you still need multiple pieces of information remembered from the merge operation in order for git-merge-file to be able to regenerate the conflict correctly in general. In particular, you need the OIDs and the filenames. Trying to regenerate a conflict without remembering those from the merge step would only work for common cases, but would be problematic in the face of either renames being involved or recursive merges or both. And if you need to remember information from the merge step, then why not remember the actual conflicts (or at least the tree OID generated by the merge operation, which has the conflicts embedded within it)? I know, I know, there's probably just historical cruft that needs cleaning up, and I don't think any of this matters to the patch at hand since it's independently useful. It just sounds like a system has been set up that has some rough edge cases caused by a poor splitting. > -- > brian m. carlson (he/him or they/them) > Toronto, Ontario, CA