Lines Matching +full:check +full:- +full:patch

12 -------------------------
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
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
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 -
70 development history.  An inconvenient patch (one which breaks bisection,
72 made to disappear from the history entirely.  A patch series can be
76 ability to revise history can help in the creation of clean patch sets with
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
94 override this check, and there may be times when it is necessary to rewrite
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
125 	to trust things *without* then having to go and check every
135 right, request that the tree be included in linux-next.
140 you may have to add a "From:" line to the patch if it has been relayed to
145 pull.  The git request-pull command can be helpful in this regard; it will
146 format the request as other developers expect, and will also check to be
152 -----------------
163 developer who may well feel nervous about questioning code - in public -
180 by the patch as a whole is a good thing for the kernel or not.  Yet others
181 will check for problematic locking, excessive stack usage, possible
183 documentation, adverse effects on performance, user-space ABI changes, etc.
187 There is no strict requirement to use specific tags like ``Reviewed-by``.
192 maintainers will not know that the reviewer has looked at the patch at all!
194 Last but not least patch review may become a negative process, focused