Re: vendor imports beyond the committers guide?
Date: Thu, 07 Mar 2024 17:58:15 UTC
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. -- Gleb Smirnoff