Re: vendor imports beyond the committers guide?

From: Warner Losh <>
Date: Thu, 07 Mar 2024 18:04:53 UTC
On Thu, Mar 7, 2024 at 9:58 AM 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.

It's for the downsides that we don't do this in the FreeBSD tree except for
zfs. And even there it causes problems with bisecting.

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

It also would bloat the cloned FreeBSD repo. We already have
enough bloat there w/o unduly adding to it.

> Bjoern, can you please point me at upstream source of truth?
> Is it a repo, or what is it.

I'd rather we just import the couple of versions we have in the tree.
While the full history might theoretically be useful, I don't think it
is warranted in this case.