LZ4: vendoring in the kernel [LWN.net]

LZ4: vendoring in the kernel

Posted Feb 2, 2017 13:57 UTC (Thu) by daurnimator (guest, #92358)
Parent article: LZ4: vendoring in the kernel

I'm wondering if anyone has tried to extract and merge the changes via 'git subtree'.
I don't know if the kernel does it already: but if you vendor code from a git-based project into a git-based project, **please** use 'git subtree' to do it.

to post comments

LZ4: vendoring in the kernel

Posted Feb 2, 2017 14:51 UTC (Thu) by epa (subscriber, #39769) [Link] (2 responses)

Git subtree sounds good, but in fact you don't need anything too fancy to make sure you correctly track and reapply local patches.

Make a branch at the point where LZ4 code was first copied to the kernel. Working on that branch, upgrade the LZ4 code to the latest release. Then when you merge the branch back in, conflict resolution will automatically notice the locally applied changes to LZ4 in the meantime, either patching them in or flagging them as conflicts. As a final check you can diff the resulting LZ4 code against the vanilla LZ4 latest version to make sure the local patches still make sense.

LZ4: vendoring in the kernel

Posted Feb 2, 2017 14:56 UTC (Thu) by daurnimator (guest, #92358) [Link] (1 responses)

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

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