This is an automated email from the ASF dual-hosted git repository. flimzy pushed a commit to branch main in repository https://gitbox.apache.org/repos/asf/couchdb-documentation.git
The following commit(s) were added to refs/heads/main by this push: new ac84181 More inclusive terminology pt 1 (#599) ac84181 is described below commit ac8418183d5c22556f4e2ea12872ff1a444a6938 Author: Simon Dahlbacka <simon.dahlba...@ecraft.com> AuthorDate: Mon Oct 12 11:12:59 2020 +0300 More inclusive terminology pt 1 (#599) * use blocklist instead of Blacklist * use allowlist instead of whitelist * use main instead of master (when talking about branches) --- src/config/auth.rst | 2 +- src/config/indexbuilds.rst | 2 +- src/replication/conflicts.rst | 38 +++++++++++++++++++------------------- 3 files changed, 21 insertions(+), 21 deletions(-) diff --git a/src/config/auth.rst b/src/config/auth.rst index d0d5f5d..705c771 100644 --- a/src/config/auth.rst +++ b/src/config/auth.rst @@ -231,7 +231,7 @@ Authentication Configuration public_fields = first_name, last_name, contacts, url .. note:: - Using the ``public_fields`` whitelist for user document properties + Using the ``public_fields`` allowlist for user document properties requires setting the :option:`couch_httpd_auth/users_db_public` option to ``true`` (the latter option has no other purpose):: diff --git a/src/config/indexbuilds.rst b/src/config/indexbuilds.rst index fb406c7..103633c 100644 --- a/src/config/indexbuilds.rst +++ b/src/config/indexbuilds.rst @@ -49,7 +49,7 @@ following settings. database. If the difference is larger than the threshold defined here the background job will only be allowed to run in the main queue. Defaults to 1000. -.. config:section:: ken.ignore :: Auto-Indexing Blacklist +.. config:section:: ken.ignore :: Auto-Indexing Blocklist Entries in this configuration section can be used to tell the background indexer to skip over specific database shard files. The key must be the exact name of the shard with the diff --git a/src/replication/conflicts.rst b/src/replication/conflicts.rst index 2341fb9..67675dd 100644 --- a/src/replication/conflicts.rst +++ b/src/replication/conflicts.rst @@ -595,9 +595,9 @@ is an SHA1 hash of the tip commit. If you are replicating with one or more peers, a separate branch is made for each of those peers. For example, you might have:: - master -- my local branch - remotes/foo/master -- branch on peer 'foo' - remotes/bar/master -- branch on peer 'bar' + main -- my local branch + remotes/foo/main -- branch on peer 'foo' + remotes/bar/main -- branch on peer 'bar' In the regular workflow, replication is a "pull", importing changes from a remote peer into the local repository. A "pull" does two things: first "fetch" @@ -609,24 +609,24 @@ Now let's consider the business card. Alice has created a Git repo containing this, where ``AAAAAAAA`` is the SHA1 of the commit:: ---------- desktop ---------- ---------- laptop ---------- - master: AAAAAAAA master: AAAAAAAA - remotes/laptop/master: AAAAAAAA remotes/desktop/master: AAAAAAAA + main: AAAAAAAA main: AAAAAAAA + remotes/laptop/main: AAAAAAAA remotes/desktop/main: AAAAAAAA Now she makes a change on the desktop, and commits it into the desktop repo; then she makes a different change on the laptop, and commits it into the laptop repo:: ---------- desktop ---------- ---------- laptop ---------- - master: BBBBBBBB master: CCCCCCCC - remotes/laptop/master: AAAAAAAA remotes/desktop/master: AAAAAAAA + main: BBBBBBBB main: CCCCCCCC + remotes/laptop/main: AAAAAAAA remotes/desktop/main: AAAAAAAA Now on the desktop she does ``git pull laptop``. First, the remote objects are copied across into the local repo and the remote tracking branch is updated:: ---------- desktop ---------- ---------- laptop ---------- - master: BBBBBBBB master: CCCCCCCC - remotes/laptop/master: CCCCCCCC remotes/desktop/master: AAAAAAAA + main: BBBBBBBB main: CCCCCCCC + remotes/laptop/main: CCCCCCCC remotes/desktop/main: AAAAAAAA .. note:: The repo still contains AAAAAAAA because commits BBBBBBBB and CCCCCCCC @@ -639,15 +639,15 @@ the parent commit to ``CCCCCCCC`` is ``AAAAAAAA``, it takes a diff between If this is successful, then you'll get a new version with a merge commit:: ---------- desktop ---------- ---------- laptop ---------- - master: DDDDDDDD master: CCCCCCCC - remotes/laptop/master: CCCCCCCC remotes/desktop/master: AAAAAAAA + main: DDDDDDDD main: CCCCCCCC + remotes/laptop/main: CCCCCCCC remotes/desktop/main: AAAAAAAA Then Alice has to logon to the laptop and run ``git pull desktop``. A similar process occurs. The remote tracking branch is updated:: ---------- desktop ---------- ---------- laptop ---------- - master: DDDDDDDD master: CCCCCCCC - remotes/laptop/master: CCCCCCCC remotes/desktop/master: DDDDDDDD + main: DDDDDDDD main: CCCCCCCC + remotes/laptop/main: CCCCCCCC remotes/desktop/main: DDDDDDDD Then a merge takes place. This is a special case: ``CCCCCCCC`` is one of the parent commits of ``DDDDDDDD``, so the laptop can `fast forward` update from @@ -655,8 +655,8 @@ parent commits of ``DDDDDDDD``, so the laptop can `fast forward` update from This leaves the final state as:: ---------- desktop ---------- ---------- laptop ---------- - master: DDDDDDDD master: DDDDDDDD - remotes/laptop/master: CCCCCCCC remotes/desktop/master: DDDDDDDD + main: DDDDDDDD main: DDDDDDDD + remotes/laptop/main: CCCCCCCC remotes/desktop/main: DDDDDDDD Now this is all and good, but you may wonder how this is relevant when thinking about CouchDB. @@ -678,10 +678,10 @@ multiple remote tracking branches, some of which may match your local branch, some of which may be behind you, and some of which may be ahead of you (i.e. contain changes that you haven't yet merged):: - master: AAAAAAAA - remotes/foo/master: BBBBBBBB - remotes/bar/master: CCCCCCCC - remotes/baz/master: AAAAAAAA + main: AAAAAAAA + remotes/foo/main: BBBBBBBB + remotes/bar/main: CCCCCCCC + remotes/baz/main: AAAAAAAA Note that each peer is explicitly tracked, and therefore has to be explicitly created. If a peer becomes stale or is no longer needed, it's up to you to