|
Size: 1821
Comment:
|
Size: 1769
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 6: | Line 6: |
| * * Use {{{hg export}}} where possible. | * Use {{{hg export}}} where possible. |
| Line 8: | Line 8: |
| * * Make sure your description is complete. | * Make sure your description is complete. |
| Line 10: | Line 10: |
| * * Make sure your description starts with a reasonable one-line summary. | * Make sure your description starts with a reasonable one-line summary. |
| Line 14: | Line 14: |
| * * In general, think of ["Mercurial"] as following a process similar to KernelPractice. * * ["Serve"] a ["Repository"] over HTTP that contains your changes, so Matt only needs to ["Pull"] from it if he likes the changes. |
* In general, think of ["Mercurial"] as following a process similar to KernelPractice. * ["Serve"] a ["Repository"] over HTTP that contains your changes, so Matt only needs to ["Pull"] from it if he likes the changes. |
| Line 17: | Line 17: |
| * * If you're sending ["Patch"]es, attach only one per message. | * If you're sending ["Patch"]es, attach only one per message. |
| Line 19: | Line 19: |
| * * Make sure the ["Patch"]es you send apply cleanly against the current ["Tip"]. * * MIME-attached ["Patch"]es are preferable to cut-and-paste copies of ["Patch"]es, because many mailers will screw up the white space of inline ["Patch"]es, so they will not apply cleanly. * * Each ["Patch"] should make sense in and of itself, and not contain pieces of unrelated stuff that you noticed and decided to fix up. * * Follow the prevailing coding style in the code you're modifying, not what you think it''ought'' to be. * * Patches should not contain tab characters. * * Patches should not contain trailing white space. * * If you are cleaning up white space, do it in a self-contained patch that contains no functional changes. |
* Make sure the ["Patch"]es you send apply cleanly against the current ["Tip"]. * MIME-attached ["Patch"]es are preferable to cut-and-paste copies of ["Patch"]es, because many mailers will screw up the white space of inline ["Patch"]es, so they will not apply cleanly. * Each ["Patch"] should make sense in and of itself, and not contain pieces of unrelated stuff that you noticed and decided to fix up. * Follow the prevailing coding style in the code you're modifying, not what you think it''ought'' to be. * Patches should not contain tab characters. * Patches should not contain trailing white space. * If you are cleaning up white space, do it in a self-contained patch that contains no functional changes. |
Contributing changes to [Mercurial]
Matt is trying to streamline his fairly complex process of merging ["Patch"]es from the MailingList. So please try to do the following:
Use hg export where possible.
- This will get your name in the changelog without any extra editing on his part.
- Make sure your description is complete.
If using hg export, he wants the descriptionin the exported patch.
- Make sure your description starts with a reasonable one-line summary.
Some other useful guidelines:
In general, think of ["Mercurial"] as following a process similar to KernelPractice.
- ["Serve"] a ["Repository"] over HTTP that contains your changes, so Matt only needs to ["Pull"] from it if he likes the changes.
Send your changes as ["Patch"]es to the MailingList anyway, so other people on the mailing list can review what you're doing.
- If you're sending ["Patch"]es, attach only one per message.
If you are emailing a ["Patch"] directly to Matt, copy the MailingList.
- Make sure the ["Patch"]es you send apply cleanly against the current ["Tip"].
- MIME-attached ["Patch"]es are preferable to cut-and-paste copies of ["Patch"]es, because many mailers will screw up the white space of inline ["Patch"]es, so they will not apply cleanly.
- Each ["Patch"] should make sense in and of itself, and not contain pieces of unrelated stuff that you noticed and decided to fix up.
Follow the prevailing coding style in the code you're modifying, not what you think itought to be.
- Patches should not contain tab characters.
- Patches should not contain trailing white space.
- If you are cleaning up white space, do it in a self-contained patch that contains no functional changes.