Lines Matching +full:in +full:- +full:tree
1 .. SPDX-License-Identifier: GPL-2.0
8 Git source-code management system. Git is a powerful tool with a lot of
10 ways to use those features. This document looks in particular at the use
11 of rebasing and merging. Maintainers often get in trouble when they use
15 One thing to be aware of in general is that, unlike many other projects,
16 the kernel community is not scared by seeing merge commits in its
30 - Changing the parent (starting) commit upon which a series of patches is
33 release. We'll call this operation "reparenting" in the discussion
36 - Changing the history of a set of patches by fixing (or deleting) broken
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
50 tree and built on it; modifying your tree will create pain for them. If
51 work is in need of rebasing, that is usually a sign that it is not yet
54 That said, there are always exceptions. Some trees (linux-next being
58 testing services. If you do expose a branch that may be unstable in
61 - Do not rebase a branch that contains history created by others. If you
64 exceptions, for example, a broken commit in a tree like this should be
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
72 as the new base. The kernel is often in a relatively unstable state
76 the -rc releases) to move to.
78 - Realize that reparenting a patch series (or making significant history
79 modifications) changes the environment in which it was developed and,
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
97 Merging is a common operation in the kernel development process; the 5.1
98 development cycle included 1,126 merge commits - nearly 9% of the total.
99 Kernel work is accumulated in over 100 different subsystem trees, each of
104 Many projects require that branches in pull requests be based on the
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
111 the mainline. The best practices to follow differ in those two situations.
113 Merging from lower-level trees
114 ------------------------------
117 lower-level maintainers sending pull requests to the higher levels. Acting
119 is as it should be. In fact, subsystem maintainers may want to use
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
132 history into your tree, you cannot rebase that branch, even if you
136 --------------------------------------
146 gives a warm, fuzzy feeling of being up-to-date. But this temptation
151 from elsewhere in the community and make it hard to ensure that the work
153 also obscure problems with the development process in your tree; they can
154 hide interactions with other trees that should not be happening (often) in
155 a well-managed branch.
158 sure to document *why* it was required in the commit message. As always,
159 merge to a well-known stable point, rather than to some random commit.
160 Even then, you should not back merge a tree above your immediate upstream
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
165 maintainer merges with the upstream in order to resolve merge conflicts
171 in the 5.1 development cycle) and has gotten quite good at conflict
172 resolution - often better than the developers involved.
176 Linus in the pull request that the conflict will happen; if nothing else,
179 how you would resolve things. Mention that branch in your pull request,
182 Even in the absence of known conflicts, doing a test merge before sending a
184 didn't see from linux-next and helps to understand exactly what you are
187 Another reason for doing merges of upstream or another subsystem tree is to
189 sometimes a cross-merge with another tree is the best way to resolve them;
190 as always, in such situations, the merge commit should explain why the
195 needed. Merging another subsystem tree to resolve a dependency risks
196 bringing in other bugs and should almost never be done. If that subsystem
197 tree fails to be pulled upstream, whatever problems it had will block the
198 merging of your tree as well. Preferable alternatives include agreeing
199 with the maintainer to carry both sets of changes in one of the trees or
204 stabilize in the mainline.
210 the development cycle in order to pick up changes and fixes done elsewhere
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