Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 31 Jan 2024 23:05:45 +0000
From:      Jessica Clarke <jrtc27@freebsd.org>
To:        Jung-uk Kim <jkim@FreeBSD.org>
Cc:        Gleb Smirnoff <glebius@freebsd.org>, Cy Schubert <Cy.Schubert@cschubert.com>, "src-committers@freebsd.org" <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:  <DD196DC5-B524-4934-9EB3-DDE99D750C7C@freebsd.org>
In-Reply-To: <fb2dd88f-4ea4-4601-92ea-f9be0b69369d@FreeBSD.org>
References:  <202401310406.40V46AUG000837@gitrepo.freebsd.org> <3BE4D4E2-DFF3-4F68-B3D3-8CE9C27089A5@freebsd.org> <20240130205710.11cf19cf@slippy> <ZbrMEhdc720oKgcV@cell.glebi.us> <fb2dd88f-4ea4-4601-92ea-f9be0b69369d@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 31 Jan 2024, at 22:57, Jung-uk Kim <jkim@FreeBSD.org> wrote:
>=20
> 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.
>=20
> 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? :-(

Yes, a plain git merge is wrong, what you=E2=80=99re looking for is git =
subtree
merge. There=E2=80=99s a section[1] in the Committer=E2=80=99s Guide =
documenting the
whole process. Note MFCs are different and should be cherry-picks like
normal commits, albeit with slightly special options[2].

Jess

[1] =
https://docs.freebsd.org/en/articles/committers-guide/#vendor-import-git
[2] =
https://docs.freebsd.org/en/articles/committers-guide/#_mfc_a_vendor_impor=
t




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DD196DC5-B524-4934-9EB3-DDE99D750C7C>