Lines Matching refs:be

5 number of topics which can be helpful for developers wanting to become a
23 teach the reader how to use git; that would be sufficient material for a
24 long document in its own right.  Instead, the focus here will be on how git
36 available to others.  A git-using developer should be able to obtain a copy
42 heads, etc.  It can all be a little intimidating at the outset, but the
45 Using git to generate patches for submission by email can be a good
49 will, of course, need a server that can be pulled from.  Setting up such a
57 of development can be separated into a separate "topic branch" and
61 Publicly-available branches should be created with care; merge in patches
67 say, or which has some other sort of obvious bug) can be fixed in place or
68 made to disappear from the history entirely.  A patch series can be
70 you have been working on it for months.  Changes can be transparently
83 which has been exported to others should generally be seen as immutable
87 changes should not be rewritten.  Git will attempt to enforce this rule if
90 override this check, and there may be times when it is necessary to rewrite
92 linux-next is one example.  But such actions should be rare.  This is one
93 of the reasons why development should be done in private branches (which
94 can be rewritten if necessary) and only moved into public branches when
99 edge.  For a private branch, rebasing can be an easy way to keep up with
101 world.  Once that happens, a full merge must be done.  Merging occasionally
106 perform test merges in a private branch.  The git "rerere" tool can be
118 	need to know that you know what you're doing, and I need to be able
126 should not be making changes to the core memory management code.  And, most
129 right, request that the tree be included in linux-next.
137 When requesting a pull, be sure to give all the relevant information: where
139 pull.  The git request-pull command can be helpful in this regard; it will
140 format the request as other developers expect, and will also check to be
147 topics" on the grounds that even beginning kernel developers should be
154 Reviewing code can be an intimidating prospect, especially for a new kernel
157 the most experienced developers can be improved, though.  Perhaps the best