Lines Matching full:your
31 3. Pushing Out Your Changes
35 3.4 How to get your changes into the main sources
61 When contributing with code, you agree to put your changes and new code under
78 to the code and to be allowed by your employer or whatever to hand over that
79 patch/code to us. We will credit you for your changes as far as possible, to
81 always provide us with your full real name when contributing!
94 Try using a non-confusing naming scheme for your new functions and variable
116 Comment your source code extensively using C comments (/* comment */), DO NOT
128 Keep your functions small. If they're small you avoid a lot of mistakes and
163 Please try to get the latest available sources to make your patches
172 small description of your fix or your new features with every contribution so
190 verified your changes.
192 3. Pushing Out Your Changes
198 your changes straight into the git repo instead of sending changes by mail as
208 You then proceed and edit all the files you like and you commit them to your
213 As usual, group your commits so that you commit all changes that at once that
217 Once you have done all your commits and you're happy with what you see, you
218 can make patches out of your changes that are suitable for mailing:
222 This creates files in your local directory named NNNN-[name].patch for each
230 Keep a copy of the unmodified curl sources. Make your changes in a separate
256 3.4 How to get your changes into the main sources
258 Submit your patch to the curl-library mailing list.
262 Make sure your patch adheres to the source indent and coding style of already
267 that you're not very anxious to get your patch accepted and I tend to simply
270 If you've followed the above paragraphs and your patch still hasn't been
292 and make sure that you have your own user and email setup correctly in git
