^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) .. SPDX-License-Identifier: GPL-2.0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) ====================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4) Rebasing and merging
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) ====================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7) Maintaining a subsystem, as a general rule, requires a familiarity with the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8) Git source-code management system. Git is a powerful tool with a lot of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9) features; as is often the case with such tools, there are right and wrong
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) ways to use those features. This document looks in particular at the use
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) of rebasing and merging. Maintainers often get in trouble when they use
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12) those tools incorrectly, but avoiding problems is not actually all that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) hard.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) One thing to be aware of in general is that, unlike many other projects,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) the kernel community is not scared by seeing merge commits in its
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) development history. Indeed, given the scale of the project, avoiding
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) merges would be nearly impossible. Some problems encountered by
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) maintainers result from a desire to avoid merges, while others come from
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) merging a little too often.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) Rebasing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) ========
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) "Rebasing" is the process of changing the history of a series of commits
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) within a repository. There are two different types of operations that are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) referred to as rebasing since both are done with the ``git rebase``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28) command, but there are significant differences between them:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) - Changing the parent (starting) commit upon which a series of patches is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31) built. For example, a rebase operation could take a patch set built on
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) the previous kernel release and base it, instead, on the current
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) release. We'll call this operation "reparenting" in the discussion
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) below.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) - Changing the history of a set of patches by fixing (or deleting) broken
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37) commits, adding patches, adding tags to commit changelogs, or changing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) the order in which commits are applied. In the following text, this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39) type of operation will be referred to as "history modification"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) The term "rebasing" will be used to refer to both of the above operations.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) Used properly, rebasing can yield a cleaner and clearer development
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43) history; used improperly, it can obscure that history and introduce bugs.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) There are a few rules of thumb that can help developers to avoid the worst
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) perils of rebasing:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) - History that has been exposed to the world beyond your private system
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) should usually not be changed. Others may have pulled a copy of your
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50) tree and built on it; modifying your tree will create pain for them. If
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) work is in need of rebasing, that is usually a sign that it is not yet
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52) ready to be committed to a public repository.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) That said, there are always exceptions. Some trees (linux-next being
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) a significant example) are frequently rebased by their nature, and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56) developers know not to base work on them. Developers will sometimes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) expose an unstable branch for others to test with or for automated
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) testing services. If you do expose a branch that may be unstable in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) this way, be sure that prospective users know not to base work on it.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) - Do not rebase a branch that contains history created by others. If you
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) have pulled changes from another developer's repository, you are now a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) custodian of their history. You should not change it. With few
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64) exceptions, for example, a broken commit in a tree like this should be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) explicitly reverted rather than disappeared via history modification.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) - Do not reparent a tree without a good reason to do so. Just being on a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68) newer base or avoiding a merge with an upstream repository is not
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) generally a good reason.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) - If you must reparent a repository, do not pick some random kernel commit
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72) as the new base. The kernel is often in a relatively unstable state
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) between release points; basing development on one of those points
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) increases the chances of running into surprising bugs. When a patch
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75) series must move to a new base, pick a stable point (such as one of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) the -rc releases) to move to.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78) - Realize that reparenting a patch series (or making significant history
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79) modifications) changes the environment in which it was developed and,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) likely, invalidates much of the testing that was done. A reparented
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81) patch series should, as a general rule, be treated like new code and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82) retested from the beginning.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84) A frequent cause of merge-window trouble is when Linus is presented with a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) patch series that has clearly been reparented, often to a random commit,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) shortly before the pull request was sent. The chances of such a series
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87) having been adequately tested are relatively low - as are the chances of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) the pull request being acted upon.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90) If, instead, rebasing is limited to private trees, commits are based on a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91) well-known starting point, and they are well tested, the potential for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92) trouble is low.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94) Merging
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95) =======
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97) Merging is a common operation in the kernel development process; the 5.1
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98) development cycle included 1,126 merge commits - nearly 9% of the total.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99) Kernel work is accumulated in over 100 different subsystem trees, each of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) which may contain multiple topic branches; each branch is usually developed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) independently of the others. So naturally, at least one merge will be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102) required before any given branch finds its way into an upstream repository.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) Many projects require that branches in pull requests be based on the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105) current trunk so that no merge commits appear in the history. The kernel
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106) is not such a project; any rebasing of branches to avoid merges will, most
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) likely, lead to trouble.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) Subsystem maintainers find themselves having to do two types of merges:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) from lower-level subsystem trees and from others, either sibling trees or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111) the mainline. The best practices to follow differ in those two situations.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) Merging from lower-level trees
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114) ------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116) Larger subsystems tend to have multiple levels of maintainers, with the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117) lower-level maintainers sending pull requests to the higher levels. Acting
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118) on such a pull request will almost certainly generate a merge commit; that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119) is as it should be. In fact, subsystem maintainers may want to use
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120) the --no-ff flag to force the addition of a merge commit in the rare cases
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) where one would not normally be created so that the reasons for the merge
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122) can be recorded. The changelog for the merge should, for any kind of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123) merge, say *why* the merge is being done. For a lower-level tree, "why" is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124) usually a summary of the changes that will come with that pull.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126) Maintainers at all levels should be using signed tags on their pull
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127) requests, and upstream maintainers should verify the tags when pulling
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128) branches. Failure to do so threatens the security of the development
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129) process as a whole.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131) As per the rules outlined above, once you have merged somebody else's
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132) history into your tree, you cannot rebase that branch, even if you
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133) otherwise would be able to.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135) Merging from sibling or upstream trees
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136) --------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138) While merges from downstream are common and unremarkable, merges from other
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139) trees tend to be a red flag when it comes time to push a branch upstream.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140) Such merges need to be carefully thought about and well justified, or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) there's a good chance that a subsequent pull request will be rejected.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143) It is natural to want to merge the master branch into a repository; this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144) type of merge is often called a "back merge". Back merges can help to make
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145) sure that there are no conflicts with parallel development and generally
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146) gives a warm, fuzzy feeling of being up-to-date. But this temptation
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147) should be avoided almost all of the time.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149) Why is that? Back merges will muddy the development history of your own
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150) branch. They will significantly increase your chances of encountering bugs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151) from elsewhere in the community and make it hard to ensure that the work
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152) you are managing is stable and ready for upstream. Frequent merges can
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153) also obscure problems with the development process in your tree; they can
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154) hide interactions with other trees that should not be happening (often) in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155) a well-managed branch.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157) That said, back merges are occasionally required; when that happens, be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158) sure to document *why* it was required in the commit message. As always,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159) merge to a well-known stable point, rather than to some random commit.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160) Even then, you should not back merge a tree above your immediate upstream
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161) tree; if a higher-level back merge is really required, the upstream tree
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162) should do it first.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164) One of the most frequent causes of merge-related trouble is when a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165) maintainer merges with the upstream in order to resolve merge conflicts
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166) before sending a pull request. Again, this temptation is easy enough to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167) understand, but it should absolutely be avoided. This is especially true
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168) for the final pull request: Linus is adamant that he would much rather see
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169) merge conflicts than unnecessary back merges. Seeing the conflicts lets
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170) him know where potential problem areas are. He does a lot of merges (382
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171) in the 5.1 development cycle) and has gotten quite good at conflict
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172) resolution - often better than the developers involved.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174) So what should a maintainer do when there is a conflict between their
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175) subsystem branch and the mainline? The most important step is to warn
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176) Linus in the pull request that the conflict will happen; if nothing else,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177) that demonstrates an awareness of how your branch fits into the whole. For
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178) especially difficult conflicts, create and push a *separate* branch to show
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179) how you would resolve things. Mention that branch in your pull request,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180) but the pull request itself should be for the unmerged branch.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182) Even in the absence of known conflicts, doing a test merge before sending a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183) pull request is a good idea. It may alert you to problems that you somehow
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184) didn't see from linux-next and helps to understand exactly what you are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185) asking upstream to do.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187) Another reason for doing merges of upstream or another subsystem tree is to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188) resolve dependencies. These dependency issues do happen at times, and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189) sometimes a cross-merge with another tree is the best way to resolve them;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190) as always, in such situations, the merge commit should explain why the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191) merge has been done. Take a moment to do it right; people will read those
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192) changelogs.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 194) Often, though, dependency issues indicate that a change of approach is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 195) needed. Merging another subsystem tree to resolve a dependency risks
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 196) bringing in other bugs and should almost never be done. If that subsystem
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 197) tree fails to be pulled upstream, whatever problems it had will block the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 198) merging of your tree as well. Preferable alternatives include agreeing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 199) with the maintainer to carry both sets of changes in one of the trees or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 200) creating a topic branch dedicated to the prerequisite commits that can be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 201) merged into both trees. If the dependency is related to major
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 202) infrastructural changes, the right solution might be to hold the dependent
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 203) commits for one development cycle so that those changes have time to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 204) stabilize in the mainline.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 205)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 206) Finally
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 207) =======
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 208)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 209) It is relatively common to merge with the mainline toward the beginning of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 210) the development cycle in order to pick up changes and fixes done elsewhere
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 211) in the tree. As always, such a merge should pick a well-known release
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 212) point rather than some random spot. If your upstream-bound branch has
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 213) emptied entirely into the mainline during the merge window, you can pull it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 214) forward with a command like::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 215)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 216) git merge v5.2-rc1^0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 217)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 218) The "^0" will cause Git to do a fast-forward merge (which should be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 219) possible in this situation), thus avoiding the addition of a spurious merge
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 220) commit.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 221)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 222) The guidelines laid out above are just that: guidelines. There will always
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 223) be situations that call out for a different solution, and these guidelines
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 224) should not prevent developers from doing the right thing when the need
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 225) arises. But one should always think about whether the need has truly
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 226) arisen and be prepared to explain why something abnormal needs to be done.
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags