| 1 |
commit: 5121332b708a733b2b52975a1100b847dcb0c60a |
| 2 |
Author: Michał Górny <mgorny <AT> gentoo <DOT> org> |
| 3 |
AuthorDate: Sat Oct 14 18:45:55 2017 +0000 |
| 4 |
Commit: Göktürk Yüksek <gokturk <AT> gentoo <DOT> org> |
| 5 |
CommitDate: Wed Jan 3 04:42:55 2018 +0000 |
| 6 |
URL: https://gitweb.gentoo.org/proj/devmanual.git/commit/?id=5121332b |
| 7 |
|
| 8 |
ebuild-maintenance/git: Try to describe atomic commits better (GLEP 66) |
| 9 |
|
| 10 |
ebuild-maintenance/git/text.xml | 50 ++++++++++++++++++++++++++++++----------- |
| 11 |
1 file changed, 37 insertions(+), 13 deletions(-) |
| 12 |
|
| 13 |
diff --git a/ebuild-maintenance/git/text.xml b/ebuild-maintenance/git/text.xml |
| 14 |
index dfc3d5b..c61589d 100644 |
| 15 |
--- a/ebuild-maintenance/git/text.xml |
| 16 |
+++ b/ebuild-maintenance/git/text.xml |
| 17 |
@@ -148,21 +148,45 @@ in the commit. |
| 18 |
</subsection> |
| 19 |
|
| 20 |
<subsection> |
| 21 |
-<title>Git Commit Policy</title> |
| 22 |
+<title>Atomic commits</title> |
| 23 |
<body> |
| 24 |
|
| 25 |
-<ul> |
| 26 |
-<li>Always test that <path>package.mask</path> is okay by doing |
| 27 |
-<c>emerge --pretend mypkg</c> before you commit and check |
| 28 |
-that it doesn't contain any conflicts.</li> |
| 29 |
-<li>Always commit the updated <path>package.mask</path> before |
| 30 |
-the updated package.</li> |
| 31 |
-<li>Always do atomic commits; if you commit a package with a new license, |
| 32 |
-or that is masked, then first commit the revised <path>package.mask</path> and/or license, |
| 33 |
-then commit the ebuild, patches |
| 34 |
-and <uri link="::ebuild-writing/misc-files/metadata">metadata.xml</uri> all in <b>one</b> go |
| 35 |
-.</li> |
| 36 |
-</ul> |
| 37 |
+<p> |
| 38 |
+Whenever possible, use atomic commits. Try to split your changes into logical |
| 39 |
+commits, abiding by the following three rules as much as possible: |
| 40 |
+</p> |
| 41 |
+ |
| 42 |
+<ol> |
| 43 |
+<li> |
| 44 |
+Do not include multiple irrelevant changes in a single commit. However, make |
| 45 |
+sure not to split relevant changes unnecessarily. For example, if a version bump |
| 46 |
+requires changes in the ebuild, it is correct to perform them in a single |
| 47 |
+commit. However, if you are fixing an additional bug that has been present |
| 48 |
+in the previous version, the fix belongs in a separate commit. |
| 49 |
+</li> |
| 50 |
+ |
| 51 |
+<li> |
| 52 |
+Split commits at logical unit boundaries. When updating multiple packages, |
| 53 |
+preferably use a single commit for each package. Avoid combining changes |
| 54 |
+to ebuilds, eclasses, licenses, profiles etc. in a single commit. However, |
| 55 |
+do not split relevant or interdependent changes within a single package. |
| 56 |
+</li> |
| 57 |
+ |
| 58 |
+<li> |
| 59 |
+Avoid creating commits introducing a temporary breakage. Unless impossible, |
| 60 |
+add packages in dependency install order. Add licenses before the packages |
| 61 |
+needing them. Commit <path>package.mask</path> and other profile changes before |
| 62 |
+ebuilds relying on them. Usually it is also acceptable to include those changes |
| 63 |
+along with the commit adding the package. |
| 64 |
+</li> |
| 65 |
+</ol> |
| 66 |
+ |
| 67 |
+<p> |
| 68 |
+Please note that revision bumps count as side effects of the changes requiring |
| 69 |
+them and do not belong in separate commits. When doing multiple irrelevant |
| 70 |
+changes that require a revision bump, it is only necessary to bump the revision |
| 71 |
+in the first commit in the series introduced by a single push. |
| 72 |
+</p> |
| 73 |
|
| 74 |
</body> |
| 75 |
</subsection> |
Archives