|
|
Log in / Subscribe / Register

LZ4: vendoring in the kernel

LZ4: vendoring in the kernel

Posted Feb 2, 2017 14:56 UTC (Thu) by daurnimator (guest, #92358)
In reply to: LZ4: vendoring in the kernel by epa
Parent article: LZ4: vendoring in the kernel

The benefit of using git subtrees is that you get commit-by-commit history on both sides:
- you'd be able to extract the kernel commits that applied to the LZ4 library, and send a PR upstream (or allow them to cherry pick).
- when pulling down changes, you get to maintain original commit messages (possibly e.g. mentioning CVEs) and dates as well as author attribution


to post comments

LZ4: vendoring in the kernel

Posted Feb 2, 2017 16:43 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

We use something like git subtree at work, but not exactly (we evaluated subtree, but found it lacking for what we needed). What we do is keep a git mirror of the repo on our infra to which we add a for/$project branch. On this branch, we hold patches for integration into the build, fixes, symbol mangling patches, etc. Patches which should go upstream get issues opened for doing so.

To import, we take a subset of that repo (we usually do not care about docs and the like), put it in a tree, make a commit with its parent pointing to the previous commit (initial imports use a new root commit), and then merge into place using -Xsubtree. This allows us to keep the history as one would expect as well as not inflating our repo size with the full history of the import. Git checks ensure that the imported directory is only changed via this mechanism (and also protects against "evil merges").


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds