Date: Thu, 22 Apr 2021 06:26:56 GMT From: =?utf-8?B?RmVybmFuZG8gQXBlc3RlZ3XDrWE=?= <fernape@FreeBSD.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org Subject: git: 69fe0eea04 - main - [committers-guide] Consistent use of Subversion Message-ID: <202104220626.13M6Qucv013898@gitrepo.freebsd.org>
next in thread | raw e-mail | index | archive | help
The branch main has been updated by fernape: URL: https://cgit.FreeBSD.org/doc/commit/?id=69fe0eea04c0e6927b90d5f8f4b5e0c45cea267d commit 69fe0eea04c0e6927b90d5f8f4b5e0c45cea267d Author: Fernando Apesteguía <fernape@FreeBSD.org> AuthorDate: 2021-04-21 16:46:51 +0000 Commit: Fernando Apesteguía <fernape@FreeBSD.org> CommitDate: 2021-04-22 06:22:52 +0000 [committers-guide] Consistent use of Subversion Majority of the uses capitalize the first letter. Let the rest do the same. Approved by: 0mp Differential Revision: https://reviews.freebsd.org/D29888 --- .../content/en/articles/committers-guide/_index.adoc | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/documentation/content/en/articles/committers-guide/_index.adoc b/documentation/content/en/articles/committers-guide/_index.adoc index ffab5e8ddd..f55b9dc0bc 100644 --- a/documentation/content/en/articles/committers-guide/_index.adoc +++ b/documentation/content/en/articles/committers-guide/_index.adoc @@ -499,7 +499,7 @@ Stashing is also integrated with the 'git pull' command: just add '--autostash' ===== Keeping a local branch [[keeping_a_local_branch]] It is much easier to keep a local branch with Git than Subversion. -In subversion you need to merge the commit, and resolve the conflicts. +In Subversion you need to merge the commit, and resolve the conflicts. This is manageable, but can lead to a convoluted history that's hard to upstream should that ever be necessary, or hard to replicate if you need to do so. Git also allows one to merge, along with the same problems. That's one way to manage the branch, but it's the least flexible. @@ -811,7 +811,7 @@ When committing source commits to stable and releng branches, we have the follow * Avoid introducing known breakage into stable and releng branches. * Allow developers to determine which changes have or have not been landed from one branch to another. -With subversion, we used the following practices to achieve these goals: +With Subversion, we used the following practices to achieve these goals: * Using 'MFC' and 'MFS' tags to mark commits that merged changes from another branch. * Squashing fixup commits into the main commit when merging a change. @@ -819,7 +819,7 @@ With subversion, we used the following practices to achieve these goals: With Git, we will need to use different strategies to achieve the same goals. This document aims to define best practices when merging source commits using Git that achieve these goals. -In general, we aim to use Git's native support to achieve these goals rather than enforcing practices built on subversion's model. +In general, we aim to use Git's native support to achieve these goals rather than enforcing practices built on Subversion's model. One general note: due to technical differences with Git, we will not be using Git "merge commits" (created via `git merge`) in stable or releng branches. Instead, when this document refers to "merge commits", it means a commit originally made to `main` that is replicated or "landed" to a stable branch, or a commit from a stable branch that is replicated to a releng branch with some variation of `git cherry-pick`. @@ -851,7 +851,7 @@ When merging multiple commits, keep all the "cherry picked from" lines. ===== Trim Metadata? -One area that was not clearly documented with subversion (or even CVS) is how to format metadata in log messages for MFC commits. +One area that was not clearly documented with Subversion (or even CVS) is how to format metadata in log messages for MFC commits. Should it include the metadata from the original commit unchanged, or should it be altered to reflect information about the MFC commit itself? Historical practice has varied, though some of the variance is by field. @@ -1399,7 +1399,7 @@ Either build it from ports, or install it using pkg (though some folks might use If you have no changes pending, the migration is straightforward. In this, you abandon the Subversion tree and clone the Git repository. -It's likely best to retain your subversion tree, in case there's something you've forgotten about there. +It's likely best to retain your Subversion tree, in case there's something you've forgotten about there. First, let's clone the repository: [source,shell] @@ -2915,7 +2915,7 @@ Phabricator accounts cannot be merged, please do not open a new account. Besides the repository meisters, there are other FreeBSD project members and teams whom you will probably get to know in your role as a committer. Briefly, and by no means all-inclusively, these are: `{doceng}`:: -doceng is the group responsible for the documentation build infrastructure, approving new documentation committers, and ensuring that the FreeBSD website and documentation on the FTP site is up to date with respect to the subversion tree. +doceng is the group responsible for the documentation build infrastructure, approving new documentation committers, and ensuring that the FreeBSD website and documentation on the FTP site is up to date with respect to the Subversion tree. It is not a conflict resolution body. The vast majority of documentation related discussion takes place on the {freebsd-doc}. More details regarding the doceng team can be found in its https://www.FreeBSD.org/internal/doceng/[charter].
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202104220626.13M6Qucv013898>