From owner-dev-commits-doc-all@freebsd.org Thu Apr 22 06:26:56 2021 Return-Path: Delivered-To: dev-commits-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 67BB05E0D4D for ; Thu, 22 Apr 2021 06:26:56 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FQnWh2Wwyz3CYD; Thu, 22 Apr 2021 06:26:56 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4970A14BD9; Thu, 22 Apr 2021 06:26:56 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.16.1/8.16.1) with ESMTP id 13M6Quk1013899; Thu, 22 Apr 2021 06:26:56 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.16.1/8.16.1/Submit) id 13M6Qucv013898; Thu, 22 Apr 2021 06:26:56 GMT (envelope-from git) Date: Thu, 22 Apr 2021 06:26:56 GMT Message-Id: <202104220626.13M6Qucv013898@gitrepo.freebsd.org> To: doc-committers@FreeBSD.org, dev-commits-doc-all@FreeBSD.org From: =?utf-8?B?RmVybmFuZG8gQXBlc3RlZ3XDrWE=?= Subject: git: 69fe0eea04 - main - [committers-guide] Consistent use of Subversion MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: fernape X-Git-Repository: doc X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 69fe0eea04c0e6927b90d5f8f4b5e0c45cea267d Auto-Submitted: auto-generated X-BeenThere: dev-commits-doc-all@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for all branches of the doc repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2021 06:26:56 -0000 The branch main has been updated by fernape: URL: https://cgit.FreeBSD.org/doc/commit/?id=69fe0eea04c0e6927b90d5f8f4b5e0c45cea267d commit 69fe0eea04c0e6927b90d5f8f4b5e0c45cea267d Author: Fernando Apesteguía AuthorDate: 2021-04-21 16:46:51 +0000 Commit: Fernando Apesteguía 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].