From: Ondrej Mosnáček on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/commit/691f37398b27a8a10853eb989dbbf92df51522a9#note_528346762 The problem with the `git merge` approach would be if you wanted to get the infra stuff on top of some older mainline tag/commit (e.g. for bisecting). If the branch is just a couple commits on top of `master`, you can easily rebase/cherry-pick it anywhere you want (modulo merge conflicts). If it had `master` continually merged into it, then it would be infeasible to rebase it (I think... or the result would be messy because of the merge commits) and if you tried to merge it on top of an old revision, it would pull the whole `master` with it. As a kernel developer, I often use the ARK tree to scratch-build almost- mainline testing kernels (with some patches on top) in Koji, so having a branch that can be easily moved around would be a plus for me. _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
