I'm currently trying to update the linux kernel used in a xilinx SoC, my company has an internal repo/fork of xilinx open source linux with a bunch of kernel drivers for our custom hardware & kernel config stuff.

Our current fork is based on xlnx_rebase_v5.4 & we're trying to upgrade to xlnx_rebase_v5.15_LTS. So far, the best strategy I have for doing this update is to create a new fork of the 5.15 xilinx branch, then cherry pick all our commits needed from the old (internal) fork (which will probably be all of them). This results in a confusing git history, tons of merge conflicts and breaking any current feature branches being worked on by my coworkers.

I'm totally new to kernel development (and working on projects of this scale in general) so I'm wondering if there's a better way to do this? Maintaining traceability of our work is very important for the project so messing up the git history is my biggest concern.

  • 3
    Is there a reason why creating a new branch from the common ancestor of your fork and the official fork doesn't work? Then you can merge your fork and the official fork into that branch. That would preserve history. May 13 at 12:24
  • 2
    And sometimes history is just messy because branches have diverged from each other. Messy history isn't necessarily bad. Having no history is worse. May 13 at 12:25
  • 2
    Is there a common ancestor for your fork and the official fork? That's the burning question. May 13 at 12:26
  • 2
    If you need to cherry pick all your changes, could you just rebase onto the new code?
    – Cole Tobin
    May 13 at 18:18
  • Note that if you have customers using your modified Linux kernel, you have the GPL to attend to. You may want to consider checking if the organiszation is willing to submit kernel patches upstream so your kernel is unmodified. May 17 at 14:00


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.