From nobody Wed Jan 31 15:35:37 2024 X-Original-To: dev-commits-src-main@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TQ5j40Yh0z58lJG for ; Wed, 31 Jan 2024 15:35:52 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TQ5j35NQVz4672 for ; Wed, 31 Jan 2024 15:35:51 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-557dcb0f870so5971071a12.2 for ; Wed, 31 Jan 2024 07:35:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1706715348; x=1707320148; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Md9shYk7884Q+svMcpmmr9uXN25VVY9UCrrHUUvDb10=; b=hKxYG+jW/txIo/AtMIeaIVGCW1zDtYjWUodgRSQfTK3eOXZI2WyRwtsaCiKlcAJCD5 UZdCNR6lEra3pTttmrtaq1LqJp516veBvAknX9tTFr0JaKgq6G5Dod4jbE39g2KgRamg ftnfX5ePDutgUbRVFUwSxkE8BZHXFEFO7V7XGl+M2u3GFZdeHcNig2Nqh/MlGi23XjKX P33+TLb7wMi/kgAm/Kh+2Gs8IqbBWm7oCkJOYEpojsLhaYtlKKni7PVvX82hwSe9EmYF lLtZpuX10N49/3bwsUdZUB45toibWYIrxcVWaUg3BnFRdPd/jWpv3rTYWGJ31fRil0/1 yYgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706715348; x=1707320148; h=cc: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=Md9shYk7884Q+svMcpmmr9uXN25VVY9UCrrHUUvDb10=; b=HKjQRwGMoiETdlc7xmHHDFDeHxjfPTJdX3RFnmJTFWnG3KzvybA+mch7yG6D3LioKA S+PY0AbD3hHvEfmwHEd8cB3Gn/uAEW1Kqc4knVtufgsPOdyfpVTOu+vu8CEgtDxz71es gNxzevdRZHvobKTOKePGNkIT3hSqhiJ7Is+LsjlL+vCEnK7ZIFQDc1QxBOs+p2a0zQrL ND+NcolvDbdzvF6/LxF4Pf08AhWzGNPNvfRnPgHBRSue2/RR10NrPPsnSwsdZmNLclKA 0MHT0vYiexfhFIA1oC8MbXDc3lObCPBnOo2Jx/pKPjyERzHqyq/oZ4zjR7aM7Jjg5jN7 ePDQ== X-Gm-Message-State: AOJu0YxzbeuqesJvHkvuAaQe7K3AqY9F8F4ISZpVX7rnclNbYC14rK/h Zu6hYA1/RBVwb2DGSDBhzBHzBREU6HgaaNXj7zCwCBbGlhJ7Qa1kFTMIo/WINhcU8ZDx+9OjOhu mf2QYXwTkOrjXvYafuqIa3cWrVvlmu19fXGwiIw== X-Google-Smtp-Source: AGHT+IHG65gN96+jC3twuSlcLsmHSXmTPUUCVYGh5SEzW7rSlr89eHKGpbmDhmtfJkGaJZWf0SEOCC9YhVkdqKyCU5E= X-Received: by 2002:a05:6402:1a2f:b0:55f:a102:55 with SMTP id be15-20020a0564021a2f00b0055fa1020055mr348289edb.10.1706715348218; Wed, 31 Jan 2024 07:35:48 -0800 (PST) List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-main@freebsd.org X-BeenThere: dev-commits-src-main@freebsd.org MIME-Version: 1.0 References: <202401310406.40V46AUG000837@gitrepo.freebsd.org> <3BE4D4E2-DFF3-4F68-B3D3-8CE9C27089A5@freebsd.org> <20240130205710.11cf19cf@slippy> <20240131051743.EDDE915B@slippy.cwsent.com> In-Reply-To: From: Warner Losh Date: Wed, 31 Jan 2024 08:35:37 -0700 Message-ID: Subject: Re: git: 722b16673c40 - main - acpica: Import ACPICA 20230331 To: Ed Maste Cc: Cy Schubert , Jessica Clarke , Jung-uk Kim , src-committers , "" , "" Content-Type: multipart/alternative; boundary="00000000000010461a06103fa2eb" X-Rspamd-Queue-Id: 4TQ5j35NQVz4672 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] --00000000000010461a06103fa2eb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 31, 2024 at 7:50=E2=80=AFAM Ed Maste wrote= : > On Wed, 31 Jan 2024 at 00:17, Cy Schubert > wrote: > > > > but would the history graph be different? Or does that matter? > > It will be different - a merge would be > > main --- A --- B ---- C ---- D > / / > / / > vendor --- X ------------ Y > > cherry-pick will be: > > main --- A --- B ---- C ---- D' > / > / > vendor --- X ------------ Y > > as you mention D and D' have the same contents, but D' has only one > parent. When searching for unmerged changes commit Y might be > reported, but that view of the history won't otherwise cause material > issues. > > If there's another update in the future and it's merged we'll be back to: > > main --- A --- B ---- C ---- D' --- E > / / > / / > vendor --- X ------------ Y ---- Z > > In this case Y would no longer get reported as needing to be merged. > There's an important detail here. If D really is identical to D' except for the second parent and its delta is the same as from X to Y, then when it comes time to merge Z to create E, we'll be fine. Git understands how to cope with cherry-picked changed in this situation because the change hash (different than the commit hash) will be the same. However, if there was any change at all, no matter how trivial or trifling, then it will consider those changes in need of merging, and conflicts are possible during that process.It will require that you do additional work to sort them out when you sorted out them already in the cherry-pick. If we always merge, the only conflicts that are possible are actual conflicts. It's why we don't do this by cherry-pick generally. While rerere can code adequately, the data for rerer= e is on an individual's machine, while the merge info metadata is inside the pushed repo. Warner --00000000000010461a06103fa2eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jan 31, 2024 at 7:50=E2=80=AF= AM Ed Maste <emaste@freebsd.org> wrote:
On = Wed, 31 Jan 2024 at 00:17, Cy Schubert <Cy.Schubert@cschubert.com> wrote:
>
>=C2=A0 but would the history graph be different? Or does that matter?
It will be different - a merge would be

main=C2=A0 =C2=A0--- A --- B ---- C ---- D
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0/
vendor --- X ------------ Y

cherry-pick will be:

main=C2=A0 =C2=A0--- A --- B ---- C ---- D'
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /
vendor --- X ------------ Y

as you mention D and D' have the same contents, but D' has only one=
parent. When searching for unmerged changes commit Y might be
reported, but that view of the history won't otherwise cause material issues.

If there's another update in the future and it's merged we'll b= e back to:

main=C2=A0 =C2=A0--- A --- B ---- C ---- D' --- E
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/
vendor --- X ------------ Y ---- Z

In this case Y would no longer get reported as needing to be merged.

There's an important detail here. If D really = is identical to D' except
for the secon= d parent and its delta is the same as from X to Y, then when
it comes time to merge Z to create E, we'll be fine. = Git understands how
to cope with cherry-pic= ked changed in this situation because the change
hash (different than the commit hash) will be the same. However, if t= here was
any change at all, no matter how t= rivial or trifling, then it will consider
t= hose changes in need of merging, and conflicts are possible during that
process.It will require that you do additional= work to sort them out when you
sorted out = them already in the cherry-pick. If we always merge, the only
conflicts that are possible are actual conflicts. It'= ;s why we don't do this by
cherry-pick = generally. While rerere can code adequately, the data for rerere
is on an individual's machine, while the merge in= fo metadata is inside the
pushed repo.

Warner
=
--00000000000010461a06103fa2eb--