| 1 |
commit: 1536e0fe2f087a555580b9f21de8162e08caa890 |
| 2 |
Author: Ulrich Müller <ulm <AT> gentoo <DOT> org> |
| 3 |
AuthorDate: Tue Mar 30 16:09:41 2021 +0000 |
| 4 |
Commit: Ulrich Müller <ulm <AT> gentoo <DOT> org> |
| 5 |
CommitDate: Tue Mar 30 16:09:41 2021 +0000 |
| 6 |
URL: https://gitweb.gentoo.org/proj/devmanual.git/commit/?id=1536e0fe |
| 7 |
|
| 8 |
ebuild-maintenance/git: Formatting fixes |
| 9 |
|
| 10 |
Signed-off-by: Ulrich Müller <ulm <AT> gentoo.org> |
| 11 |
|
| 12 |
ebuild-maintenance/git/text.xml | 125 ++++++++++++++++++++++------------------ |
| 13 |
1 file changed, 69 insertions(+), 56 deletions(-) |
| 14 |
|
| 15 |
diff --git a/ebuild-maintenance/git/text.xml b/ebuild-maintenance/git/text.xml |
| 16 |
index fc2738a..0cad9bf 100644 |
| 17 |
--- a/ebuild-maintenance/git/text.xml |
| 18 |
+++ b/ebuild-maintenance/git/text.xml |
| 19 |
@@ -2,8 +2,8 @@ |
| 20 |
<guide self="ebuild-maintenance/git/"> |
| 21 |
<chapter> |
| 22 |
<title>Git for Gentoo Developers</title> |
| 23 |
- |
| 24 |
<body> |
| 25 |
+ |
| 26 |
<p> |
| 27 |
This guide covers git usage instructions and policies specific to Gentoo ebuild |
| 28 |
development. It assumes that the readers possess basic git knowledge. |
| 29 |
@@ -125,12 +125,18 @@ used. The valid uses of git include: |
| 30 |
</p> |
| 31 |
|
| 32 |
<ul> |
| 33 |
-<li>creating commits spanning multiple packages and/or multiple areas |
| 34 |
-of the Gentoo repository (eclasses, licenses, profiles…),</li> |
| 35 |
-<li>amending a commit created via <c>repoman commit</c> or <c>pkgdev commit</c> |
| 36 |
-with additional files or fixups,</li> |
| 37 |
-<li>combining multiple commits created via <c>repoman commit</c> or |
| 38 |
-<c>pkgdev commit</c> using <c>git rebase</c>.</li> |
| 39 |
+ <li> |
| 40 |
+ creating commits spanning multiple packages and/or multiple areas of the |
| 41 |
+ Gentoo repository (eclasses, licenses, profiles…), |
| 42 |
+ </li> |
| 43 |
+ <li> |
| 44 |
+ amending a commit created via <c>repoman commit</c> or <c>pkgdev commit</c> |
| 45 |
+ with additional files or fixups, |
| 46 |
+ </li> |
| 47 |
+ <li> |
| 48 |
+ combining multiple commits created via <c>repoman commit</c> or |
| 49 |
+ <c>pkgdev commit</c> using <c>git rebase</c>. |
| 50 |
+ </li> |
| 51 |
</ul> |
| 52 |
|
| 53 |
<p> |
| 54 |
@@ -138,8 +144,8 @@ Whenever <c>repoman</c> or <c>pkgdev</c> is not used to commit, you need to |
| 55 |
manually verify all packages affected by the commit using <c>repoman full</c> or |
| 56 |
<c>pkgcheck scan --commits</c>. When using <c>repoman</c>, it won't be aware of |
| 57 |
staged changes, so ensure that all files are included in the commit. |
| 58 |
-Also, when using <c>git</c> manually, you must perform a manual sign-off |
| 59 |
-to the <uri link="https://www.gentoo.org/glep/glep-0076.html#certificate-of-origin"> |
| 60 |
+Also, when using <c>git</c> manually, you must perform a manual sign-off to the |
| 61 |
+<uri link="https://www.gentoo.org/glep/glep-0076.html#certificate-of-origin"> |
| 62 |
Certificate of Origin</uri> using the <c>-s</c> or <c>--signoff</c> option |
| 63 |
with your git commit commands. Make sure you have read and understand the |
| 64 |
actual Certificate. |
| 65 |
@@ -158,28 +164,26 @@ commits, abiding by the following three rules as much as possible: |
| 66 |
</p> |
| 67 |
|
| 68 |
<ol> |
| 69 |
-<li> |
| 70 |
-Do not include multiple irrelevant changes in a single commit. However, make |
| 71 |
-sure not to split relevant changes unnecessarily. For example, if a version bump |
| 72 |
-requires changes in the ebuild, it is correct to perform them in a single |
| 73 |
-commit. However, if you are fixing an additional bug that has been present |
| 74 |
-in the previous version, the fix belongs in a separate commit. |
| 75 |
-</li> |
| 76 |
- |
| 77 |
-<li> |
| 78 |
-Split commits at logical unit boundaries. When updating multiple packages, |
| 79 |
-preferably use a single commit for each package. Avoid combining changes |
| 80 |
-to ebuilds, eclasses, licenses, profiles etc. in a single commit. However, |
| 81 |
-do not split relevant or interdependent changes within a single package. |
| 82 |
-</li> |
| 83 |
- |
| 84 |
-<li> |
| 85 |
-Avoid creating commits introducing a temporary breakage. Unless impossible, |
| 86 |
-add packages in dependency install order. Add licenses before the packages |
| 87 |
-needing them. Commit <c>package.mask</c> and other profile changes before |
| 88 |
-ebuilds relying on them. Usually it is also acceptable to include those changes |
| 89 |
-along with the commit adding the package. |
| 90 |
-</li> |
| 91 |
+ <li> |
| 92 |
+ Do not include multiple irrelevant changes in a single commit. However, |
| 93 |
+ make sure not to split relevant changes unnecessarily. For example, if a |
| 94 |
+ version bump requires changes in the ebuild, it is correct to perform them |
| 95 |
+ in a single commit. However, if you are fixing an additional bug that has |
| 96 |
+ been present in the previous version, the fix belongs in a separate commit. |
| 97 |
+ </li> |
| 98 |
+ <li> |
| 99 |
+ Split commits at logical unit boundaries. When updating multiple packages, |
| 100 |
+ preferably use a single commit for each package. Avoid combining changes |
| 101 |
+ to ebuilds, eclasses, licenses, profiles etc. in a single commit. However, |
| 102 |
+ do not split relevant or interdependent changes within a single package. |
| 103 |
+ </li> |
| 104 |
+ <li> |
| 105 |
+ Avoid creating commits introducing a temporary breakage. Unless impossible, |
| 106 |
+ add packages in dependency install order. Add licenses before the packages |
| 107 |
+ needing them. Commit <c>package.mask</c> and other profile changes before |
| 108 |
+ ebuilds relying on them. Usually it is also acceptable to include those |
| 109 |
+ changes along with the commit adding the package. |
| 110 |
+ </li> |
| 111 |
</ol> |
| 112 |
|
| 113 |
<p> |
| 114 |
@@ -220,13 +224,15 @@ appropriately: |
| 115 |
</p> |
| 116 |
|
| 117 |
<ul> |
| 118 |
-<li><c>${CATEGORY}/${PN}:</c> Single Package (Note that <c>repoman commit</c> |
| 119 |
-and <c>pkgdev commit</c> will automatically insert this for you)</li> |
| 120 |
-<li><c>${CATEGORY}:</c> Package Category</li> |
| 121 |
-<li><c>profiles:</c> Profile Directory</li> |
| 122 |
-<li><c>${ECLASS}.eclass:</c> Eclass Directotry</li> |
| 123 |
-<li><c>licenses:</c> Licenses Directory</li> |
| 124 |
-<li><c>metadata:</c> Metadata Directory</li> |
| 125 |
+ <li> |
| 126 |
+ <c>${CATEGORY}/${PN}:</c> Single Package (Note that <c>repoman commit</c> |
| 127 |
+ and <c>pkgdev commit</c> will automatically insert this for you) |
| 128 |
+ </li> |
| 129 |
+ <li><c>${CATEGORY}:</c> Package Category</li> |
| 130 |
+ <li><c>profiles:</c> Profile Directory</li> |
| 131 |
+ <li><c>${ECLASS}.eclass:</c> Eclass Directotry</li> |
| 132 |
+ <li><c>licenses:</c> Licenses Directory</li> |
| 133 |
+ <li><c>metadata:</c> Metadata Directory</li> |
| 134 |
</ul> |
| 135 |
|
| 136 |
<p> |
| 137 |
@@ -266,24 +272,31 @@ are optionally used in Gentoo: |
| 138 |
</p> |
| 139 |
|
| 140 |
<ul> |
| 141 |
-<li><c>Bug:</c> Use this to reference bugs <e>without</e> closing them. |
| 142 |
-The value is a URL to the bug. If multiple bugs need to be referenced, |
| 143 |
-each one should be listed in a separate <c>Bug</c> tag. If a bug |
| 144 |
-on Gentoo Bugzilla, or an issue or a pull request on GitHub |
| 145 |
-is referenced, a reference to the commit will be added |
| 146 |
-automatically.</li> |
| 147 |
-<li><c>Closes:</c> Use this to reference bugs and close them |
| 148 |
-automatically. Alike <c>Bug:</c>, the value is a single URL to the bug, |
| 149 |
-and multiple tags can be used to close multiple bugs. If a bug on Gentoo |
| 150 |
-Bugzilla, or an issue or a pull request on a GitHub repository |
| 151 |
-mirrored by Gentoo is referenced, it will be closed (as fixed) |
| 152 |
-automatically with reference to the commit.</li> |
| 153 |
-<li><c>Package-Manager:</c> This is automatically inserted by |
| 154 |
-<c>repoman commit</c> and it specifies the version of |
| 155 |
-<c>sys-apps/portage</c> on the system.</li> |
| 156 |
-<li><c>RepoMan-Options:</c> This is automatically inserted by |
| 157 |
-<c>repoman commit</c> and records the options passed to repoman (such |
| 158 |
-as --force) for the commit.</li> |
| 159 |
+ <li> |
| 160 |
+ <c>Bug:</c> Use this to reference bugs <e>without</e> closing them. |
| 161 |
+ The value is a URL to the bug. If multiple bugs need to be referenced, |
| 162 |
+ each one should be listed in a separate <c>Bug</c> tag. If a bug on |
| 163 |
+ Gentoo Bugzilla, or an issue or a pull request on GitHub is referenced, |
| 164 |
+ a reference to the commit will be added automatically. |
| 165 |
+ </li> |
| 166 |
+ <li> |
| 167 |
+ <c>Closes:</c> Use this to reference bugs and close them automatically. |
| 168 |
+ Alike <c>Bug:</c>, the value is a single URL to the bug, and multiple tags |
| 169 |
+ can be used to close multiple bugs. If a bug on Gentoo Bugzilla, or an |
| 170 |
+ issue or a pull request on a GitHub repository mirrored by Gentoo is |
| 171 |
+ referenced, it will be closed (as fixed) automatically with reference |
| 172 |
+ to the commit. |
| 173 |
+ </li> |
| 174 |
+ <li> |
| 175 |
+ <c>Package-Manager:</c> This is automatically inserted by |
| 176 |
+ <c>repoman commit</c> and it specifies the version of |
| 177 |
+ <c>sys-apps/portage</c> on the system. |
| 178 |
+ </li> |
| 179 |
+ <li> |
| 180 |
+ <c>RepoMan-Options:</c> This is automatically inserted by |
| 181 |
+ <c>repoman commit</c> and records the options passed to repoman (such as |
| 182 |
+ --force) for the commit. |
| 183 |
+ </li> |
| 184 |
</ul> |
| 185 |
|
| 186 |
<p> |
Archives