Lines Matching full:that
12 those tools incorrectly, but avoiding problems is not actually all that
15 One thing to be aware of in general is that, unlike many other projects,
26 within a repository. There are two different types of operations that are
43 history; used improperly, it can obscure that history and introduce bugs.
45 There are a few rules of thumb that can help developers to avoid the worst
48 - History that has been exposed to the world beyond your private system
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
59 this way, be sure that prospective users know not to base work on it.
61 - Do not rebase a branch that contains history created by others. If you
78 - Realize that reparenting a patch series (or making significant history
80 likely, invalidates much of the testing that was done. A reparented
85 patch series that has clearly been reparented, often to a random commit,
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
118 on such a pull request will almost certainly generate a merge commit; that
121 where one would not normally be created so that the reasons for the merge
124 usually a summary of the changes that will come with that pull.
132 history into your tree, you cannot rebase that branch, even if you
141 there's a good chance that a subsequent pull request will be rejected.
145 sure that there are no conflicts with parallel development and generally
149 Why is that? Back merges will muddy the development history of your own
151 from elsewhere in the community and make it hard to ensure that the work
154 hide interactions with other trees that should not be happening (often) in
157 That said, back merges are occasionally required; when that happens, be
168 for the final pull request: Linus is adamant that he would much rather see
176 Linus in the pull request that the conflict will happen; if nothing else,
177 that demonstrates an awareness of how your branch fits into the whole. For
179 how you would resolve things. Mention that branch in your pull request,
183 pull request is a good idea. It may alert you to problems that you somehow
194 Often, though, dependency issues indicate that a change of approach is
196 bringing in other bugs and should almost never be done. If that subsystem
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
222 The guidelines laid out above are just that: guidelines. There will always
223 be situations that call out for a different solution, and these guidelines