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

From: Gleb Smirnoff <glebius_at_freebsd.org>
Date: Wed, 31 Jan 2024 22:39:14 UTC
On Tue, Jan 30, 2024 at 08:57:10PM -0800, Cy Schubert wrote:
C> > > commit 722b16673c40aedf280895f2f2f676bb494518d7
C> > > Author:     Jung-uk Kim <jkim@FreeBSD.org>
C> > > AuthorDate: 2024-01-30 21:43:45 +0000
C> > > Commit:     Jung-uk Kim <jkim@FreeBSD.org>
C> > > CommitDate: 2024-01-31 03:16:36 +0000
C> > > 
C> > >    acpica: Import ACPICA 20230331
C> > > 
C> > >    (cherry picked from commit 8e013e1e3b81740266738226667431cf5c28b17a)  
C> > 
C> > Cherry-pick not merge for a vendor merge?..
C> 
C> Probably not Kosher but, a general git question about cherry-picks vs
C> merges. A cherry-pick, without the -x but specifying the source branch,
C> results in no cherry picked merge but a merge of the last commit of the
C> source branch to the current branch.
C> 
C> Can someone explain this? And if this would be any different from a
C> merge from a branch that is ahead by one commit since the last merge?

The object hashes would be the same, but the second parent meta-data
is basically lost, although can be recorded in the commit text
message with -x.

The second parent is important. When searching for regressions you may
go into bisecting the acpica history instead of FreeBSD history once
you figured out that this is the merge that brough the regression. With
second parent this can be automated and in case of manual search still
easier to do.

So, please don't do cherry-picks instead of merges for vendor subprojects.

-- 
Gleb Smirnoff