Re: vendor imports beyond the committers guide?

From: Warner Losh <>
Date: Thu, 07 Mar 2024 18:07:52 UTC
On Thu, Mar 7, 2024 at 10:04 AM Bjoern A. Zeeb <> wrote:

> 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 messages
> 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 the
> > 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

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.