From: "Ulrich Müller" <ulm@gentoo.org>
To: gentoo-commits@lists.gentoo.org
Subject: [gentoo-commits] proj/devmanual:master commit in: ebuild-maintenance/git/
Date: Tue, 30 Mar 2021 16:10:07 +0000 (UTC) [thread overview]
Message-ID: <1617120581.1536e0fe2f087a555580b9f21de8162e08caa890.ulm@gentoo> (raw)
commit: 1536e0fe2f087a555580b9f21de8162e08caa890
Author: Ulrich Müller <ulm <AT> gentoo <DOT> org>
AuthorDate: Tue Mar 30 16:09:41 2021 +0000
Commit: Ulrich Müller <ulm <AT> gentoo <DOT> org>
CommitDate: Tue Mar 30 16:09:41 2021 +0000
URL: https://gitweb.gentoo.org/proj/devmanual.git/commit/?id=1536e0fe
ebuild-maintenance/git: Formatting fixes
Signed-off-by: Ulrich Müller <ulm <AT> gentoo.org>
ebuild-maintenance/git/text.xml | 125 ++++++++++++++++++++++------------------
1 file changed, 69 insertions(+), 56 deletions(-)
diff --git a/ebuild-maintenance/git/text.xml b/ebuild-maintenance/git/text.xml
index fc2738a..0cad9bf 100644
--- a/ebuild-maintenance/git/text.xml
+++ b/ebuild-maintenance/git/text.xml
@@ -2,8 +2,8 @@
<guide self="ebuild-maintenance/git/">
<chapter>
<title>Git for Gentoo Developers</title>
-
<body>
+
<p>
This guide covers git usage instructions and policies specific to Gentoo ebuild
development. It assumes that the readers possess basic git knowledge.
@@ -125,12 +125,18 @@ used. The valid uses of git include:
</p>
<ul>
-<li>creating commits spanning multiple packages and/or multiple areas
-of the Gentoo repository (eclasses, licenses, profiles…),</li>
-<li>amending a commit created via <c>repoman commit</c> or <c>pkgdev commit</c>
-with additional files or fixups,</li>
-<li>combining multiple commits created via <c>repoman commit</c> or
-<c>pkgdev commit</c> using <c>git rebase</c>.</li>
+ <li>
+ creating commits spanning multiple packages and/or multiple areas of the
+ Gentoo repository (eclasses, licenses, profiles…),
+ </li>
+ <li>
+ amending a commit created via <c>repoman commit</c> or <c>pkgdev commit</c>
+ with additional files or fixups,
+ </li>
+ <li>
+ combining multiple commits created via <c>repoman commit</c> or
+ <c>pkgdev commit</c> using <c>git rebase</c>.
+ </li>
</ul>
<p>
@@ -138,8 +144,8 @@ Whenever <c>repoman</c> or <c>pkgdev</c> is not used to commit, you need to
manually verify all packages affected by the commit using <c>repoman full</c> or
<c>pkgcheck scan --commits</c>. When using <c>repoman</c>, it won't be aware of
staged changes, so ensure that all files are included in the commit.
-Also, when using <c>git</c> manually, you must perform a manual sign-off
-to the <uri link="https://www.gentoo.org/glep/glep-0076.html#certificate-of-origin">
+Also, when using <c>git</c> manually, you must perform a manual sign-off to the
+<uri link="https://www.gentoo.org/glep/glep-0076.html#certificate-of-origin">
Certificate of Origin</uri> using the <c>-s</c> or <c>--signoff</c> option
with your git commit commands. Make sure you have read and understand the
actual Certificate.
@@ -158,28 +164,26 @@ commits, abiding by the following three rules as much as possible:
</p>
<ol>
-<li>
-Do not include multiple irrelevant changes in a single commit. However, make
-sure not to split relevant changes unnecessarily. For example, if a version bump
-requires changes in the ebuild, it is correct to perform them in a single
-commit. However, if you are fixing an additional bug that has been present
-in the previous version, the fix belongs in a separate commit.
-</li>
-
-<li>
-Split commits at logical unit boundaries. When updating multiple packages,
-preferably use a single commit for each package. Avoid combining changes
-to ebuilds, eclasses, licenses, profiles etc. in a single commit. However,
-do not split relevant or interdependent changes within a single package.
-</li>
-
-<li>
-Avoid creating commits introducing a temporary breakage. Unless impossible,
-add packages in dependency install order. Add licenses before the packages
-needing them. Commit <c>package.mask</c> and other profile changes before
-ebuilds relying on them. Usually it is also acceptable to include those changes
-along with the commit adding the package.
-</li>
+ <li>
+ Do not include multiple irrelevant changes in a single commit. However,
+ make sure not to split relevant changes unnecessarily. For example, if a
+ version bump requires changes in the ebuild, it is correct to perform them
+ in a single commit. However, if you are fixing an additional bug that has
+ been present in the previous version, the fix belongs in a separate commit.
+ </li>
+ <li>
+ Split commits at logical unit boundaries. When updating multiple packages,
+ preferably use a single commit for each package. Avoid combining changes
+ to ebuilds, eclasses, licenses, profiles etc. in a single commit. However,
+ do not split relevant or interdependent changes within a single package.
+ </li>
+ <li>
+ Avoid creating commits introducing a temporary breakage. Unless impossible,
+ add packages in dependency install order. Add licenses before the packages
+ needing them. Commit <c>package.mask</c> and other profile changes before
+ ebuilds relying on them. Usually it is also acceptable to include those
+ changes along with the commit adding the package.
+ </li>
</ol>
<p>
@@ -220,13 +224,15 @@ appropriately:
</p>
<ul>
-<li><c>${CATEGORY}/${PN}:</c> Single Package (Note that <c>repoman commit</c>
-and <c>pkgdev commit</c> will automatically insert this for you)</li>
-<li><c>${CATEGORY}:</c> Package Category</li>
-<li><c>profiles:</c> Profile Directory</li>
-<li><c>${ECLASS}.eclass:</c> Eclass Directotry</li>
-<li><c>licenses:</c> Licenses Directory</li>
-<li><c>metadata:</c> Metadata Directory</li>
+ <li>
+ <c>${CATEGORY}/${PN}:</c> Single Package (Note that <c>repoman commit</c>
+ and <c>pkgdev commit</c> will automatically insert this for you)
+ </li>
+ <li><c>${CATEGORY}:</c> Package Category</li>
+ <li><c>profiles:</c> Profile Directory</li>
+ <li><c>${ECLASS}.eclass:</c> Eclass Directotry</li>
+ <li><c>licenses:</c> Licenses Directory</li>
+ <li><c>metadata:</c> Metadata Directory</li>
</ul>
<p>
@@ -266,24 +272,31 @@ are optionally used in Gentoo:
</p>
<ul>
-<li><c>Bug:</c> Use this to reference bugs <e>without</e> closing them.
-The value is a URL to the bug. If multiple bugs need to be referenced,
-each one should be listed in a separate <c>Bug</c> tag. If a bug
-on Gentoo Bugzilla, or an issue or a pull request on GitHub
-is referenced, a reference to the commit will be added
-automatically.</li>
-<li><c>Closes:</c> Use this to reference bugs and close them
-automatically. Alike <c>Bug:</c>, the value is a single URL to the bug,
-and multiple tags can be used to close multiple bugs. If a bug on Gentoo
-Bugzilla, or an issue or a pull request on a GitHub repository
-mirrored by Gentoo is referenced, it will be closed (as fixed)
-automatically with reference to the commit.</li>
-<li><c>Package-Manager:</c> This is automatically inserted by
-<c>repoman commit</c> and it specifies the version of
-<c>sys-apps/portage</c> on the system.</li>
-<li><c>RepoMan-Options:</c> This is automatically inserted by
-<c>repoman commit</c> and records the options passed to repoman (such
-as --force) for the commit.</li>
+ <li>
+ <c>Bug:</c> Use this to reference bugs <e>without</e> closing them.
+ The value is a URL to the bug. If multiple bugs need to be referenced,
+ each one should be listed in a separate <c>Bug</c> tag. If a bug on
+ Gentoo Bugzilla, or an issue or a pull request on GitHub is referenced,
+ a reference to the commit will be added automatically.
+ </li>
+ <li>
+ <c>Closes:</c> Use this to reference bugs and close them automatically.
+ Alike <c>Bug:</c>, the value is a single URL to the bug, and multiple tags
+ can be used to close multiple bugs. If a bug on Gentoo Bugzilla, or an
+ issue or a pull request on a GitHub repository mirrored by Gentoo is
+ referenced, it will be closed (as fixed) automatically with reference
+ to the commit.
+ </li>
+ <li>
+ <c>Package-Manager:</c> This is automatically inserted by
+ <c>repoman commit</c> and it specifies the version of
+ <c>sys-apps/portage</c> on the system.
+ </li>
+ <li>
+ <c>RepoMan-Options:</c> This is automatically inserted by
+ <c>repoman commit</c> and records the options passed to repoman (such as
+ --force) for the commit.
+ </li>
</ul>
<p>
next reply other threads:[~2021-03-30 16:10 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-30 16:10 Ulrich Müller [this message]
-- strict thread matches above, loose matches on Subject: below --
2024-12-07 9:39 [gentoo-commits] proj/devmanual:master commit in: ebuild-maintenance/git/ Ulrich Müller
2024-04-13 19:42 Ulrich Müller
2022-11-22 4:17 Sam James
2021-09-27 10:20 Ulrich Müller
2021-03-30 16:10 Ulrich Müller
2021-02-23 8:29 Ulrich Müller
2020-01-14 20:36 Göktürk Yüksek
2019-10-29 20:49 Göktürk Yüksek
2018-01-03 4:51 Göktürk Yüksek
2018-01-03 4:51 Göktürk Yüksek
2018-01-03 4:51 Göktürk Yüksek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1617120581.1536e0fe2f087a555580b9f21de8162e08caa890.ulm@gentoo \
--to=ulm@gentoo.org \
--cc=gentoo-commits@lists.gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox