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
9 features; as is often the case with such tools, there are right and wrong
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
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
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.
106 is not such a project; any rebasing of branches to avoid merges will, most
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.
175 subsystem branch and the mainline?  The most important step is to warn
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;
191 merge has been done.  Take a moment to do it right; people will read those
202 infrastructural changes, the right solution might be to hold the dependent
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
220 should not prevent developers from doing the right thing when the need