You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

154 lines
4.3 KiB

  2. Please read the following guidelines before contributing.
  3. 1. The basic unit of contribution is a "git commit". This will be merged into
  4. master by one of the team members who will review it and sign-off/commit or
  5. reject it. If the commit is in another branch, it will added to HEAD/master
  6. using
  7. git cherry-pick -s <tree-ish>
  8. Or if the commit is submitted as a stand alone file produce by
  9. git format-patch <tree-ish>
  10. Then it will be committed by
  11. git am -s 0001-foo-bar.patch
  12. Or if the commit is submitted as a github merge request, then the github web
  13. interface can be used.
  14. 2. Work in a branch immediately off of master, do not work directly in master,
  15. and do not be afraid of creating a local branch for every experimental thing you
  16. want to try:
  17. git checkout master # make sure your on master
  18. git branch idea1 # I've got an idea, let me work on it
  19. git checkout idea1
  20. <hack ... hack ... hack>
  21. git commit -m "step1" # I like what I've done so far, but I'm not finished
  22. <hack ... hack ... hack>
  23. git commit -m "step2"
  24. <hack ... hack ... hack>
  25. git commit -m "step3"
  26. <hack ... hack ... hack>
  27. git revert <tree-ish for step2> # Wow step 2 was dumb
  28. <hack ... hack ... hack>
  29. git commit -m "step4" # Its good now, but those
  30. # commits are messy
  31. git rebase -i <tree-ish step1>^ # start a rebase on the parent of step1
  32. (drop into editor and squash commits) # note the ^ at the end!
  33. (exit editor and fix commit message)
  34. Alternatively, you can cherry-pick those commits into another prestine branch:
  35. ... its good to go! ....
  36. git checkout master
  37. git branch idea1-clean
  38. git checkout idea1-clean
  39. git cherry-pick <sha1-of-good-commit1>
  40. git cherry-pick <sha1-of-good-commit2>
  41. (pick them in any order that stacks)
  42. (you can skip commits, but do them in the correct order to avoid conflits)
  43. git rebase -i <tree-ish of sha1-of-good-commit1>^ # squash many commits into one
  44. # note the ^ at the end!
  45. Once you are done with a local branch you can delete it using
  46. git branch -D idea1
  47. You can delete a remote branch by doing
  48. git push origin :idea1
  49. 3. Your commit message should conform to the following standard:
  50. file/changed: Concice and complete statement of the purpose
  51. This is the body of the commit message. The line above is the
  52. summary. The summary should be no more than 72 chars long. The
  53. body can be more freely formatted, but make it look nice. Make
  54. sure to reference any bug reports and other contributors. Make
  55. sure the correct authorship appears. Reference any early commits
  56. by their full shaw:
  57. b52c6402b5b42620571c36c74a12dcb45ec1e0d6
  58. which you can put on its own line and indent.
  59. X-Gentoo-Bug: 400837
  60. X-Gentoo-Bug-URL:
  61. Reported-by: Snoopy Coderdog <>
  62. Signed-off-by: Anthony G. Basile <>
  63. If you commit using
  64. git commit -s
  65. your sign-off will be automatically added. If the authorship is wrong
  66. fix it by
  67. git commit -s --author="Richard Feynmann <>"
  68. If the message doesn't look right after you commit locally, you can fix it by
  69. doing
  70. git commit --amend.
  71. Then push it to your public repo.
  72. 4.a Open an issue at (using GitHub)
  74. And request a pull of your clean commit. A team member will review it,
  75. discuss it and commit it to master or reject it.
  76. 4.b Send to mailing list (using git format-patch)
  77. Make sure you are subscribe on the mailing list. If you do not, send an email to
  79. and follow instructions.
  80. When sending patches to mailing list, use
  81. git send-email --to 0001-foo-bar.patch
  82. 5. eudev is a peer-reviewed project. So even team members must ask another
  83. team member to sign-off and commit your work. The only exception are trivial
  84. commits
  85. 6. HEAD/master must always build and must always be considered stable.
  86. 7. Releases should be tagged and signed using
  87. git tag -s -u <gpg name> -m "Release X"
  88. where X is the full release number. Make sure that before you release,
  89. you change the value in AC_INIT of to match the release
  90. number.
  91. 8. Tarball releases should be made from HEAD/master at signed tagged points
  92. by doing
  94. ./configure
  95. make
  96. make dist
  97. 9. TODO: coding style for C, python, perl and autotool stuff.