Lines Matching full:to
7 works. There is still more to learn, however! This section will cover a
8 number of topics which can be helpful for developers wanting to become a
16 application. While BitKeeper was controversial, the approach to software
19 project. In current times, there are several free alternatives to
26 still being civilized by its developers. This document will not attempt to
27 teach the reader how to use git; that would be sufficient material for a
30 wish to come up to speed with git will find more information at:
38 The first order of business is to read the above sites and get a solid
39 understanding of how git works before trying to use it to make patches
40 available to others. A git-using developer should be able to obtain a copy
41 of the mainline repository, explore the revision history, commit changes to
47 concepts are not that hard to grasp with a bit of study.
49 Using git to generate patches for submission by email can be a good
50 exercise while coming up to speed.
52 When you are ready to start putting up git trees for others to look at, you
55 which is accessible to the Internet. Otherwise, free, public hosting sites
56 (Github, for example) are starting to appear on the net. Established
57 developers can get an account on kernel.org, but those are not easy to come
62 maintained independently. Branches in git are cheap, there is no reason to
64 development in any branch which you intend to ask others to pull from.
66 from development branches when they are in complete form and ready to go -
69 Git provides some powerful tools which can allow you to rewrite your
72 made to disappear from the history entirely. A patch series can be
75 shifted from one branch to another. And so on. Judicious use of git's
76 ability to revise history can help in the creation of clean patch sets with
79 Excessive use of this capability can lead to other problems, though, beyond
87 which has been exported to others should generally be seen as immutable
90 So, once you push a set of changes to your publicly-available server, those
91 changes should not be rewritten. Git will attempt to enforce this rule if
92 you try to push changes which do not result in a fast-forward merge
93 (i.e. changes which do not share the same history). It is possible to
94 override this check, and there may be times when it is necessary to rewrite
95 an exported tree. Moving changesets between trees to avoid conflicts in
102 advances, it is tempting to merge with that tree to stay on the leading
103 edge. For a private branch, rebasing can be an easy way to keep up with
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
112 so that you don't have to do the same work twice.
115 mass movement of patches from one repository to another makes it easy to
117 radar. Kernel developers tend to get unhappy when they see that kind of
119 can affect your ability to get trees pulled in the future. Quoting Linus:
123 You can send me patches, but for me to pull a git patch from you, I
124 need to know that you know what you're doing, and I need to be able
125 to trust things *without* then having to go and check every
130 To avoid this kind of situation, ensure that all patches within a given
131 branch stick closely to the associated topic; a "driver fixes" branch
132 should not be making changes to the core memory management code. And, most
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
137 If and when others start to send patches for inclusion into your tree,
138 don't forget to review them. Also ensure that you maintain the correct
140 you may have to add a "From:" line to the patch if it has been relayed to
143 When requesting a pull, be sure to give all the relevant information: where
144 your tree is, what branch to pull, and what changes will result from the
146 format the request as other developers expect, and will also check to be
147 sure that you have remembered to push those changes to the public server.
153 Some readers will certainly object to putting this section with "advanced
155 reviewing patches. It is certainly true that there is no better way to
156 learn how to program in the kernel environment than by looking at code
158 looking at code you can make a significant contribution to the process as a
177 All types of review, if they lead to better code going into the kernel, are