diff --git a/documentation/content/en/articles/committers-guide/_index.adoc b/documentation/content/en/articles/committers-guide/_index.adoc --- a/documentation/content/en/articles/committers-guide/_index.adoc +++ b/documentation/content/en/articles/committers-guide/_index.adoc @@ -499,7 +499,7 @@ ===== 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 @@ * 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 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 @@ ===== 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 @@ 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 @@ 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].