Lines Matching +full:in +full:- +full:tree
12 -------------------------
14 The use of distributed version control for the kernel began in early 2002,
19 project. In current times, there are several free alternatives to
28 long document in its own right. Instead, the focus here will be on how git
29 fits into the kernel development process in particular. Developers who
32 https://git-scm.com/
34 https://www.kernel.org/pub/software/scm/git/docs/user-manual.html
40 available to others. A git-using developer should be able to obtain a copy
42 the tree, use branches, etc. An understanding of git's tools for the
45 remote branches, the index, fast-forward merges, pushes and pulls, detached
54 server with git-daemon is relatively straightforward if you have a system
62 maintained independently. Branches in git are cheap, there is no reason to
63 not make free use of them. And, in any case, you should not do your
64 development in any branch which you intend to ask others to pull from.
65 Publicly-available branches should be created with care; merge in patches
66 from development branches when they are in complete form and ready to go -
71 say, or which has some other sort of obvious bug) can be fixed in place or
76 ability to revise history can help in the creation of clean patch sets with
81 Rewriting history will rewrite the changes contained in that history,
82 turning a tested (hopefully) kernel tree into an untested one. But, beyond
90 So, once you push a set of changes to your publicly-available server, those
92 you try to push changes which do not result in a fast-forward merge
95 an exported tree. Moving changesets between trees to avoid conflicts in
96 linux-next is one example. But such actions should be rare. This is one
97 of the reasons why development should be done in private branches (which
99 it's in a reasonably advanced state.
101 As the mainline (or other tree upon which a set of changes is based)
102 advances, it is tempting to merge with that tree to stay on the leading
104 another tree, but rebasing is not an option once a tree is exported to the
107 needlessly. Suggested technique in this case is to merge infrequently, and
108 generally only at specific release points (such as a mainline -rc
110 perform test merges in a private branch. The git "rerere" tool can be
111 useful in such situations; it remembers how merge conflicts were resolved
116 slip in ill-advised changes which go into the mainline below the review
118 thing happening; putting up a git tree with unreviewed or off-topic patches
119 can affect your ability to get trees pulled in the future. Quoting Linus:
133 importantly, do not use a git tree to bypass the review process. Post an
134 occasional summary of the tree to the relevant list, and, when the time is
135 right, request that the tree be included in linux-next.
137 If and when others start to send patches for inclusion into your tree,
139 authorship information; the git "am" tool does its best in this regard, but
144 your tree is, what branch to pull, and what changes will result from the
145 pull. The git request-pull command can be helpful in this regard; it will
152 -----------------
157 learn how to program in the kernel environment than by looking at code
158 posted by others. In addition, reviewers are forever in short supply; by
163 developer who may well feel nervous about questioning code - in public -
168 get released in this path?" will always work better than stating "the
171 Another technique that is useful in case of a disagreement is to ask for others
172 to chime in. If a discussion reaches a stalemate after a few exchanges,
173 then call for opinions of other reviewers or maintainers. Often those in
183 documentation, adverse effects on performance, user-space ABI changes, etc.
187 There is no strict requirement to use specific tags like ``Reviewed-by``.
188 In fact reviews in plain English are more informative and encouraged
195 on pointing out problems. Please throw in a compliment once in a while,