Date: Thu, 7 Mar 2024 10:07:52 -0800 From: Warner Losh <imp@bsdimp.com> To: "Bjoern A. Zeeb" <bz@freebsd.org> Cc: Gleb Smirnoff <glebius@freebsd.org>, freebsd-git@freebsd.org Subject: Re: vendor imports beyond the committers guide? Message-ID: <CANCZdfpeyoHOL4O0toLp6p=zWRKD6Ou08CH5rnnhac1yiSMfxw@mail.gmail.com> In-Reply-To: <8n0r562s-non1-5269-p649-2s8rr05op914@serrofq.bet> References: <n4p4714r-2n97-psq3-34p2-887qq0o1354q@SerrOFQ.bet> <CANCZdfpDDx=riEdExdpzmr6DHy7%2Bgpifm_1aJMcmGiSYAeVrgw@mail.gmail.com> <5pps4nrs-or51-9018-sqp4-7q69s4780r61@serrofq.bet> <Zeig9nKD-Onc58T1@cell.glebi.us> <CANCZdfqxF-oQvc_W1jMKs=F5SE13_NmtvFOnPetr5JH6fBcPaA@mail.gmail.com> <nr98n9r4-58r6-rn91-1p01-58q56260rn66@serrofq.bet> <CANCZdfpyDQPcm2O6tzF4M91u7Pw_XhA5ihpCMON8=w7-YLezpw@mail.gmail.com> <q31p1656-6r83-0099-495p-7or9377s4131@serrofq.bet> <CANCZdfrsY93UyEGo=_6X%2BpmSfAKV2LgnUZHbC6x-po0mJv0KCg@mail.gmail.com> <ZeoAN5y_gXwxbhan@cell.glebi.us> <8n0r562s-non1-5269-p649-2s8rr05op914@serrofq.bet>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000d19a65061315f483 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 7, 2024 at 10:04=E2=80=AFAM Bjoern A. Zeeb <bz@freebsd.org> wro= te: > On Thu, 7 Mar 2024, Gleb Smirnoff wrote: > > > On Wed, Mar 06, 2024 at 03:51:11PM -0800, Warner Losh wrote: > > W> If we imported each of the versions (exclusive of the cherry-picks). > in > > W> order and > > W> then merged, this would give us a better history. The commit message= s > of > > W> the old > > W> versions could include the hash where it was committed to the tree's > main > > W> branch. > > W> This might be wise, since it would allow us to add these links in th= e > > W> future if that > > W> functionality is added to git (or someone cures me of my ignorance).= I > > W> think that > > W> if these versions were trivial to get, we should do it. If they are = a > > W> hassle, then we > > W> can forego them. The possible future benefit is speculative at best, > so if > > W> there's > > W> more than a tiny amount of hassle, we should skip doing each version= . > > > > Well, if the upstream is a true git repo, then we don't need to care > > about versions, we can take it with full history as 'subtree add'. > > Then, replay our commits on top. The downside is that each file will > > have two histories, and it would require some effort when you call > > git log to get the correct one. The repo bloat will not be large as > > the objects would be the same, it would be only extra commits metadatas= . > > > > This all will look like a small version of what we have at Netflix, > > where we followed unofficial FreeBSD git repo and then switched to > > the official one. In practice it seems to work well, although a > > perfectionists would not like doubled commits deep in the past. > > > > Bjoern, can you please point me at upstream source of truth? > > Is it a repo, or what is it. > > yes, it's three or four or five different repos with the full linux > kernel in it; nothing you want. And I believe we do not do subtrees > in FreeBSD official. > If it is from the Linux Kernel, then I'd just need a directory list and a hash. And we definitely can't do a subtree merge from that repo to ours including its entire history. > I'll go and prepare the different versions locally the next days for > each driver and then we can see. > I think I just need a list of hashes and directories. I can bring it into a test vendor branch I can push to my personal github so everyone can take a look before we do the merge and make it permanent. Warner --000000000000d19a65061315f483 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Thu, Mar 7, 2024 at 10:04=E2=80=AF= AM Bjoern A. Zeeb <<a href=3D"mailto:bz@freebsd.org">bz@freebsd.org</a>&= gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0= px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Th= u, 7 Mar 2024, Gleb Smirnoff wrote:<br> <br> > On Wed, Mar 06, 2024 at 03:51:11PM -0800, Warner Losh wrote:<br> > W> If we imported each of the versions (exclusive of the cherry-pic= ks). in<br> > W> order and<br> > W> then merged, this would give us a better history. The commit mes= sages of<br> > W> the old<br> > W> versions could include the hash where it was committed to the tr= ee's main<br> > W> branch.<br> > W> This might be wise, since it would allow us to add these links i= n the<br> > W> future if that<br> > W> functionality is added to git (or someone cures me of my ignoran= ce). I<br> > W> think that<br> > W> if these versions were trivial to get, we should do it. If they = are a<br> > W> hassle, then we<br> > W> can forego them. The possible future benefit is speculative at b= est, so if<br> > W> there's<br> > W> more than a tiny amount of hassle, we should skip doing each ver= sion.<br> ><br> > Well, if the upstream is a true git repo, then we don't need to ca= re<br> > about versions, we can take it with full history as 'subtree add&#= 39;.<br> > Then, replay our commits on top. The downside is that each file will<b= r> > have two histories, and it would require some effort when you call<br> > git log to get the correct one. The repo bloat will not be large as<br= > > the objects would be the same, it would be only extra commits metadata= s.<br> ><br> > This all will look like a small version of what we have at Netflix,<br= > > where we followed unofficial FreeBSD git repo and then switched to<br> > the official one. In practice it seems to work well, although a<br> > perfectionists would not like doubled commits deep in the past.<br> ><br> > Bjoern, can you please point me at upstream source of truth?<br> > Is it a repo, or what is it.<br> <br> yes, it's three or four or five different repos with the full linux<br> kernel in it; nothing you want.=C2=A0 And I believe we do not do subtrees<b= r> in FreeBSD official.<br></blockquote><div><br></div><div>If it is from the = Linux Kernel, then I'd just need a directory list and a hash.</div><div= ><br></div><div>And we definitely can't do a subtree merge from that re= po to ours including</div><div>its entire history.=C2=A0</div><div>=C2=A0</= div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor= der-left:1px solid rgb(204,204,204);padding-left:1ex"> I'll go and prepare the different versions locally the next days for<br= > each driver and then we can see.<br></blockquote><div><br></div><div>I thin= k I just need a list of hashes and directories. I can bring it into a</div>= <div>test vendor branch I can push to my personal github so everyone can</d= iv><div>take a look before we do the merge and make it permanent.</div><div= ><br></div><div>Warner</div></div></div> --000000000000d19a65061315f483--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpeyoHOL4O0toLp6p=zWRKD6Ou08CH5rnnhac1yiSMfxw>