Differences between revisions 9 and 10
Revision 9 as of 2006-01-09 00:25:09
Size: 1998
Comment:
Revision 10 as of 2006-02-23 19:29:29
Size: 2004
Editor: LeeCantey
Comment: Reflect change of patchbomb from a script to an extension.
Deletions are marked like this. Additions are marked like this.
Line 6: Line 6:
 * Use {{{hg export}}} or the {{{patchbomb}}} script where possible.  * Use {{{hg export}}} or the {{{patchbomb}}} extension where possible.
Line 20: Line 20:
 * Inline ["Patch"]es are preferable to MIME-attached copies of ["Patch"]es, because many mailers cannot quote attachments. Inline patches are thus easier to review. Be warned that many mailers will by default screw up the white space of inline ["Patch"]es, so they will not apply cleanly. This is usually easy to work around, for example by using the {{{patchbomb}}} script.  * Inline ["Patch"]es are preferable to MIME-attached copies of ["Patch"]es, because many mailers cannot quote attachments. Inline patches are thus easier to review. Be warned that many mailers will by default screw up the white space of inline ["Patch"]es, so they will not apply cleanly. This is usually easy to work around, for example by using the {{{patchbomb}}} extension.

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 or the patchbomb extension 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 description in the exported patch.

  • Make sure your description starts with a reasonable one-line summary.
  • Send only one patch per email, as Matt's tools and processes assume this.

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 are emailing a ["Patch"] directly to Matt, copy the MailingList.

  • Make sure the ["Patch"]es you send apply cleanly against the current ["Tip"].
  • Inline ["Patch"]es are preferable to MIME-attached copies of ["Patch"]es, because many mailers cannot quote attachments. Inline patches are thus easier to review. Be warned that many mailers will by default screw up the white space of inline ["Patch"]es, so they will not apply cleanly. This is usually easy to work around, for example by using the patchbomb extension.

  • 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.

ContributingChanges (last edited 2023-04-06 07:59:14 by RaphaelGomes)