Date: Wed, 31 Jan 2024 08:35:37 -0700 From: Warner Losh <imp@bsdimp.com> To: Ed Maste <emaste@freebsd.org> Cc: Cy Schubert <Cy.Schubert@cschubert.com>, Jessica Clarke <jrtc27@freebsd.org>, Jung-uk Kim <jkim@freebsd.org>, src-committers <src-committers@freebsd.org>, "<dev-commits-src-all@freebsd.org>" <dev-commits-src-all@freebsd.org>, "<dev-commits-src-main@freebsd.org>" <dev-commits-src-main@freebsd.org> Subject: Re: git: 722b16673c40 - main - acpica: Import ACPICA 20230331 Message-ID: <CANCZdfpKpM8VBt=MgBi%2B%2BUDN0a2KuGeTzvoKRyxQaHGC57JWvw@mail.gmail.com> In-Reply-To: <CAPyFy2D=-D_eJW=GJCKThrw%2BJpuU=w2x-5KkarBmQg40SDc0EQ@mail.gmail.com> References: <202401310406.40V46AUG000837@gitrepo.freebsd.org> <3BE4D4E2-DFF3-4F68-B3D3-8CE9C27089A5@freebsd.org> <20240130205710.11cf19cf@slippy> <CANCZdfr_kWeBKH5bpWRs6XPUQfbikow8MK%2B3edmDVse7j_QsOQ@mail.gmail.com> <20240131051743.EDDE915B@slippy.cwsent.com> <CAPyFy2D=-D_eJW=GJCKThrw%2BJpuU=w2x-5KkarBmQg40SDc0EQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <emaste@freebsd.org> wrote= : > On Wed, 31 Jan 2024 at 00:17, Cy Schubert <Cy.Schubert@cschubert.com> > 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 <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jan 31, 2024 at 7:50=E2=80=AF= AM Ed Maste <<a href=3D"mailto:emaste@freebsd.org">emaste@freebsd.org</a= >> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px= 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On = Wed, 31 Jan 2024 at 00:17, Cy Schubert <<a href=3D"mailto:Cy.Schubert@cs= chubert.com" target=3D"_blank">Cy.Schubert@cschubert.com</a>> wrote:<br> ><br> >=C2=A0 but would the history graph be different? Or does that matter?<b= r> <br> It will be different - a merge would be<br> <br> main=C2=A0 =C2=A0--- A --- B ---- C ---- D<br> =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/<br> =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/<br> vendor --- X ------------ Y<br> <br> cherry-pick will be:<br> <br> main=C2=A0 =C2=A0--- A --- B ---- C ---- D'<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /<br> vendor --- X ------------ Y<br> <br> as you mention D and D' have the same contents, but D' has only one= <br> parent. When searching for unmerged changes commit Y might be<br> reported, but that view of the history won't otherwise cause material<b= r> issues.<br> <br> If there's another update in the future and it's merged we'll b= e back to:<br> <br> main=C2=A0 =C2=A0--- A --- B ---- C ---- D' --- E<br> =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/<br> =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/<br> vendor --- X ------------ Y ---- Z<br> <br> In this case Y would no longer get reported as needing to be merged.<br></b= lockquote><div><br></div>There's an important detail here. If D really = is identical to D' except</div><div class=3D"gmail_quote">for the secon= d parent and its delta is the same as from X to Y, then when</div><div clas= s=3D"gmail_quote">it comes time to merge Z to create E, we'll be fine. = Git understands how</div><div class=3D"gmail_quote">to cope with cherry-pic= ked changed in this situation because the change</div><div class=3D"gmail_q= uote">hash (different than the commit hash) will be the same. However, if t= here was</div><div class=3D"gmail_quote">any change at all, no matter how t= rivial or trifling, then it will consider</div><div class=3D"gmail_quote">t= hose changes in need of merging, and conflicts are possible during that</di= v><div class=3D"gmail_quote">process.It will require that you do additional= work to sort them out when you</div><div class=3D"gmail_quote">sorted out = them already in the cherry-pick. If we always merge, the only</div><div cla= ss=3D"gmail_quote">conflicts that are possible are actual conflicts. It'= ;s why we don't do this by</div><div class=3D"gmail_quote">cherry-pick = generally. While rerere can code adequately, the data for rerere</div><div = class=3D"gmail_quote">is on an individual's machine, while the merge in= fo metadata is inside the</div><div class=3D"gmail_quote">pushed repo.</div= ><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Warner<br>= </div></div> --00000000000010461a06103fa2eb--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpKpM8VBt=MgBi%2B%2BUDN0a2KuGeTzvoKRyxQaHGC57JWvw>