20e2c35b7
Kevin Cernekee
2010-10-17
Subject
docs: Change CVS references to Git
Binary
No binary (build failed)
Architecture & Compiler Flags
—
Build Log
(log yok)
Commit Diff GitHub →
docs/contributing.txt+32 -21
| @@ -229,8 +229,11 @@ Here are some guidelines on how to submit a patch to Busybox. | |
| Making A Patch | |
| ~~~~~~~~~~~~~~ | |
| - | If you've got anonymous CVS access set up, making a patch is simple. Just make |
| - | sure you're in the busybox/ directory and type 'cvs diff -bwu > mychanges.patch'. |
| + | If you've got anonymous Git access set up, making a patch is simple. Just make |
| + | sure you're in the busybox/ directory and type: |
| + | |
| + | git diff -b -w > mychanges.patch |
| + | |
| You can send the resulting .patch file to the mailing list with a description | |
| of what it does. (But not before you test it! See the next section for some | |
| guidelines.) It is preferred that patches be sent as attachments, but it is | |
| @@ -238,8 +241,12 @@ not required. | |
| Also, feel free to help test other people's patches and reply to them with | |
| comments. You can apply a patch by saving it into your busybox/ directory and | |
| - | typing 'patch < mychanges.patch'. Then you can recompile, see if it runs, test |
| - | if it works as advertised, and post your findings to the mailing list. |
| + | typing: |
| + | |
| + | patch -p1 < mychanges.patch |
| + | |
| + | Then you can recompile, see if it runs, test if it works as advertised, and |
| + | post your findings to the mailing list. |
| NOTE: Please do not include extraneous or irrelevant changes in your patches. | |
| Please do not try to "bundle" two patches together into one. Make single, | |
| @@ -252,7 +259,7 @@ Testing Guidelines | |
| ~~~~~~~~~~~~~~~~~~ | |
| It's considered good form to test your new feature before you submit a patch | |
| - | to the mailing list, and especially before you commit a change to CVS. Here |
| + | to the mailing list, and especially before you push a change to Git. Here |
| are some guidelines on how to test your changes. | |
| - Always test Busybox applets against GNU counterparts and make sure the | |
| @@ -348,7 +355,7 @@ responses from queries to applet maintainer or positive responses from folks | |
| on the mailing list. | |
| We've made strident efforts to put a useful "collaboration" infrastructure in | |
| - | place in the form of mailing lists, the bug tracking system, and CVS. Please |
| + | place in the form of mailing lists, the bug tracking system, and Git. Please |
| use these resources. | |
| @@ -373,39 +380,43 @@ opposite effect. | |
| - | Committing Changes to CVS |
| - | ------------------------- |
| + | Pushing Changes to Git |
| + | ---------------------- |
| If you submit several patches that demonstrate that you are a skilled and wise | |
| - | coder, you may be invited to become a committer, thus enabling you to commit |
| - | changes directly to CVS. This is nice because you don't have to wait for |
| - | someone else to commit your change for you, you can just do it yourself. |
| + | coder, you may be invited to become a committer, thus enabling you to push |
| + | changes directly to Git. This is nice because you don't have to wait for |
| + | someone else to push your change for you, you can just do it yourself. |
| But note that this is a privilege that comes with some responsibilities. You | |
| - | should test your changes before you commit them. You should also talk to an |
| + | should test your changes before you push them. You should also talk to an |
| applet maintainer before you make any kind of sweeping changes to somebody | |
| else's code. Big changes should still go to the mailing list first. Remember, | |
| being wise, polite, and discreet is more important than being clever. | |
| + | For more information on Git push access, see: |
| - | When To Commit |
| - | ~~~~~~~~~~~~~~ |
| + | http://busybox.net/developer.html |
| - | Generally, you should feel free to commit a change if: |
| + | |
| + | When To Push |
| + | ~~~~~~~~~~~~ |
| + | |
| + | Generally, you should feel free to push a change if: |
| - Your changes are small and don't touch many files | |
| - You are fixing a bug | |
| - Somebody has told you that it's okay | |
| - It's obviously the Right Thing | |
| - | The more of the above are true, the better it is to just commit a change |
| - | directly to CVS. |
| + | The more of the above are true, the better it is to just push a change |
| + | directly to Git. |
| - | When Not To Commit |
| - | ~~~~~~~~~~~~~~~~~~ |
| + | When Not To Push |
| + | ~~~~~~~~~~~~~~~~ |
| - | Even if you have commit rights, you should probably still post a patch to the |
| + | Even if you have push access, you should probably still post a patch to the |
| mailing list if: | |
| - Your changes are broad and touch many different files | |
| @@ -414,7 +425,7 @@ mailing list if: | |
| - You are not the maintainer and your changes make the maintainer cringe | |
| The more of the above are true, the better it is to post a patch to the | |
| - | mailing list instead of committing. |
| + | mailing list instead of pushing. |