The XDAndroid Project is no longer active.
This site provides archived information from while the project was under development. Some links may no longer function.
Difference between revisions of "Submitting Patches"
| [unchecked revision] | [unchecked revision] |
(Created page with 'The XDAndroid project uses git as its exclusive revision control system. When submitting patches, please perform all changes within a working git clone of the source repository. …') |
|||
| Line 5: | Line 5: | ||
<syntaxhighlight lang="ini"> | <syntaxhighlight lang="ini"> | ||
[user] | [user] | ||
| − | + | name = John Doe | |
| − | + | email = foo@bar.baz | |
</syntaxhighlight> | </syntaxhighlight> | ||
Revision as of 19:45, 28 May 2010
The XDAndroid project uses git as its exclusive revision control system. When submitting patches, please perform all changes within a working git clone of the source repository.
Commit with your name and email address, configured by repo for the XDAndroid open source tree. For repositories that are not managed by repo, edit the git configuration for the repository in .git/config and add the following lines, with changes as needed:
[user]
name = John Doe
email = foo@bar.baz
Creating a Formatted Patch
After completing work in the repository, add files as needed with git add. Commit your changes to the repository via git commit (optionally add the -a argument to include all modified files). Enter a meaningful commit message.
Finally, create a git-formatted patch with git format-patch. The format-patch command requires arguments to specify a range of commits for which patches should be created. For example, to create a patch with the last single commit: git format-patch HEAD^..HEAD
Submitting a Patch
The Development Team prefers patches that are properly git formatted. This allows the maintainers to check the patches in with no modification, while still giving credit for the commit to its original author.
Submit your patch to the developers' mailing list at developers@xdandroid.com and the appropriate maintainer will review it. If the patch is acceptable as-is, the maintainer may commit it without contacting the author first. If further development is necessary, the maintainer (or another team member) will contact the author with advice on what must be done.
