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

On 24. 1. 31., Gleb Smirnoff wrote:
> 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.

In very early days of git adoption, I once did "git merge" from vendor 
branch by the git primer and it broke git repo.  At the time, someone 
(imp?) had to manually fix it and I was told that I should never ever do 
"git merge".  Am I confused again? :-(

Jung-uk Kim