Lines Matching +full:use +full:- +full:push +full:- +full:pull

12 -------------------------
14 The use of distributed version control for the kernel began in early 2002,
27 teach the reader how to use git; that would be sufficient material for a
32 	https://git-scm.com/
34 	https://www.kernel.org/pub/software/scm/git/docs/user-manual.html
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
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
60 The normal git workflow involves the use of a lot of branches.  Each line
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 -
75 shifted from one branch to another.  And so on.  Judicious use of git's
79 Excessive use of this capability can lead to other problems, though, 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
96 linux-next is one example.  But such actions should be rare.  This is one
108 generally only at specific release points (such as a mainline -rc
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
123 	You can send me patches, but for me to pull a git patch from you, I
133 importantly, do not use a git tree to bypass the review process.  Post an
135 right, request that the tree be included in linux-next.
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
145 pull.  The git request-pull command can be helpful in this regard; it will
147 sure that you have remembered to push those changes to the public server.
152 -----------------
163 developer who may well feel nervous about questioning code - in public -
183 documentation, adverse effects on performance, user-space ABI changes, etc.
187 There is no strict requirement to use specific tags like ``Reviewed-by``.