Re: vendor imports beyond the committers guide?

From: Bjoern A. Zeeb <>
Date: Thu, 07 Mar 2024 18:17:13 UTC
On Thu, 7 Mar 2024, Warner Losh wrote:

> 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
> 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.

it's never quite that simple ;-)

You'd need to filter out the GPL files which never saw light in FreeBSD
and we did not import all subdirectories of all drivers.

Apart from that the different repo names and hashes would be in the commit

Let me do the proper due diligens.
I'll prepare them for you; will save you enough time.

I am greatful enough that you are helping to sort all this out.


Bjoern A. Zeeb                                                     r15:7