Re: vendor imports beyond the committers guide?

On Thu, Mar 7, 2024 at 9:58 AM Gleb Smirnoff <glebius@freebsd.org> 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.

Warner