Documentation/maintainer/rebasing-and-merging.rst

1 .. SPDX-License-Identifier: GPL-2.0
8 Git source-code management system.  Git is a powerful tool with a lot of
16 the kernel community is not scared by seeing merge commits in its
25 "Rebasing" is the process of changing the history of a series of commits
30  - Changing the parent (starting) commit upon which a series of patches is
36  - Changing the history of a set of patches by fixing (or deleting) broken
37    commits, adding patches, adding tags to commit changelogs, or changing
38    the order in which commits are applied.  In the following text, this
48  - History that has been exposed to the world beyond your private system
54    That said, there are always exceptions.  Some trees (linux-next being
61  - Do not rebase a branch that contains history created by others.  If you
67  - Do not reparent a tree without a good reason to do so.  Just being on a
71  - If you must reparent a repository, do not pick some random kernel commit
76    the -rc releases) to move to.
78  - Realize that reparenting a patch series (or making significant history
84 A frequent cause of merge-window trouble is when Linus is presented with a
87 having been adequately tested are relatively low - as are the chances of
90 If, instead, rebasing is limited to private trees, commits are based on a
91 well-known starting point, and they are well tested, the potential for
98 development cycle included 1,126 merge commits - nearly 9% of the total.
105 current trunk so that no merge commits appear in the history.  The kernel
110 from lower-level subsystem trees and from others, either sibling trees or
113 Merging from lower-level trees
114 ------------------------------
117 lower-level maintainers sending pull requests to the higher levels.  Acting
120 the --no-ff flag to force the addition of a merge commit in the rare cases
123 merge, say *why* the merge is being done.  For a lower-level tree, "why" is
136 --------------------------------------
146 gives a warm, fuzzy feeling of being up-to-date.  But this temptation
155 a well-managed branch.
159 merge to a well-known stable point, rather than to some random commit.
161 tree; if a higher-level back merge is really required, the upstream tree
164 One of the most frequent causes of merge-related trouble is when a
172 resolution - often better than the developers involved.
184 didn't see from linux-next and helps to understand exactly what you are
189 sometimes a cross-merge with another tree is the best way to resolve them;
200 creating a topic branch dedicated to the prerequisite commits that can be
203 commits for one development cycle so that those changes have time to
211 in the tree.  As always, such a merge should pick a well-known release
212 point rather than some random spot.  If your upstream-bound branch has
216   git merge --ff-only v5.2-rc1