Hi Robert Nelson & Friends,
I have a local Linux kernel repository that tracks firstname.lastname@example.org:beagleboard/linux.git
Each time this repository gets updated my git-pull creates numerous unmerged files to resolve by hand.
No other git project that I track (including linux-stable) behaves the same.
Can this be avoided?
I am unfamiliar with how the repo. But it may be helpful to give an idea what sort of conflicts there are? Maybe in a gist?
I’ll copy the group next time it occurs [as the last update I handled through lazy cloning and then added my patches].
I guess Robert Nelson can answer as it must be related to the way he copies his private kernel repository changes to the Beagleboard public.
Here are his latest two commit messages.
commit 112d45a5e68d615ec2add1902d7d02fefd722817 (HEAD → 4.14-rt, tag: 4.14.71-ti-rt-r79, origin/4.14-rt)
4.14 TI Delta: https://github.com/RobertCNelson/ti-linux-kernel/compare/94bc2c7230f44abaa297c44d916ecfb894246a63...c11ae464608dbf8dcb7e1318b863cb069364ad96
Correct, the "branches" get rewritten on every push, only the "tag's"
We've got a shared patch-set for many kernel releases, with various
patch's in-flight or being nuked from orbit.
We are working off a git "base" tree from ti that also has many
patches being developed and back-ported from mainline.
Plus integration of Aufs, RT, and Wireguard git repo's.
Can you (somehow) make it easier to follow the public Beagleboard kernel via the usual git-pull and git-rebase processes [to enter one’s local commits] .
Your work is greatly appreciated. The vanilla Linux-stable kernel is simply inadequate to take advantage of the full Beagleboard hardware.
Is there a published recipe explaining how you do this amalgamation?
Just use this kernel git tree instead:
no branches, it's regular synced with linus's and greg's master's so
"git pull" always works...
All my builds are tagged, so every tag ever released from the last 4-5
years is available:
This is how I do it:
git fetch beagleboard
git rebase --onto 4.14.71-ti-r79 4.14.71-ti-r78 my-branch
where "beagleboard" is the git remote for https://github.com/beagleboard/linux.git, "4.14.71-ti-r79" is the new tag I am rebasing onto, "4.14.71-ti-r78" is the previous tag my branch was based on and "my-branch" is the name of the local branch I want to rebase.
Thanks for demonstrating this git magic.
Could RCN do the same with Beagleboard/linux branches to introduce non conflicting upgrades?