Re: git: 722b16673c40 - main - acpica: Import ACPICA 20230331

From: Cy Schubert <Cy.Schubert_at_cschubert.com>
Date: Wed, 31 Jan 2024 05:17:43 UTC
In message <CANCZdfr_kWeBKH5bpWRs6XPUQfbikow8MK+3edmDVse7j_QsOQ@mail.gmail.c
om>
, Warner Losh writes:
> --00000000000054b556061036dd0f
> Content-Type: text/plain; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable
>
> On Tue, Jan 30, 2024, 9:57=E2=80=AFPM Cy Schubert <Cy.Schubert@cschubert.co=
> m> wrote:
>
> > On Wed, 31 Jan 2024 04:29:18 +0000
> > Jessica Clarke <jrtc27@freebsd.org> wrote:
> >
> > > On 31 Jan 2024, at 04:06, Jung-uk Kim <jkim@FreeBSD.org> wrote:
> > > >
> > > > The branch main has been updated by jkim:
> > > >
> > > > URL:
> > https://cgit.FreeBSD.org/src/commit/?id=3D722b16673c40aedf280895f2f2f676b=
> b494518d7
> > > >
> > > > commit 722b16673c40aedf280895f2f2f676bb494518d7
> > > > Author:     Jung-uk Kim <jkim@FreeBSD.org>
> > > > AuthorDate: 2024-01-30 21:43:45 +0000
> > > > Commit:     Jung-uk Kim <jkim@FreeBSD.org>
> > > > CommitDate: 2024-01-31 03:16:36 +0000
> > > >
> > > >    acpica: Import ACPICA 20230331
> > > >
> > > >    (cherry picked from commit
> > 8e013e1e3b81740266738226667431cf5c28b17a)
> > >
> > > Cherry-pick not merge for a vendor merge?..
> >
> > Probably not Kosher but, a general git question about cherry-picks vs
> > merges. A cherry-pick, without the -x but specifying the source branch,
> > results in no cherry picked merge but a merge of the last commit of the
> > source branch to the current branch.
> >
> > Can someone explain this? And if this would be any different from a
> > merge from a branch that is ahead by one commit since the last merge?
> >
>
> This is functionally identical in the resulting tree, except only one
> parent is recorded for the commit. If there were no fixups needed, the next
> merge would automatically skip the cherry-picked commit due the commit
> hashes matching. However if fixups were needed, there may be conflicts on
> the next merge in cases I can only hand wave about, but have hit once or
> twice. A merge seems to be better because it only looks at changes since
> the last common ancestor. I think a merge would handle the need to revert
> better, though my experience with awk is making me question that.

I understand the patches would be the same
-- 
Cheers,
Cy Schubert <Cy.Schubert@cschubert.com>
FreeBSD UNIX:  <cy@FreeBSD.org>   Web:  https://FreeBSD.org
NTP:           <cy@nwtime.org>    Web:  https://nwtime.org

			e^(i*pi)+1=0
 but would the history graph be different? Or does that matter?