Re: git: 722b16673c40 - main - acpica: Import ACPICA 20230331
- In reply to: Jung-uk Kim : "Re: git: 722b16673c40 - main - acpica: Import ACPICA 20230331"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 31 Jan 2024 23:05:45 UTC
On 31 Jan 2024, at 22:57, Jung-uk Kim <jkim@FreeBSD.org> wrote: > > 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? :-( Yes, a plain git merge is wrong, what you’re looking for is git subtree merge. There’s a section[1] in the Committer’s 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_import