docs: remove 'just' from several places to avoid triggering textlint (#…

…5556)

.githooks/README.md

@@ -1,10 +1,10 @@
 # Git hooks
 
-Hook scripts in this directory can be placed in .git/hooks to get git to help with our workflow. These are for developer use only, and have no impact by just being here in .githooks.
+Hook scripts in this directory can be placed in .git/hooks to get git to help with our workflow. These are for developer use only, and have no impact by being here in .githooks.
 
 You should also be able to link them, for example (if you don't mind if they change upstream, and don't introduce any changes of your own)
 
-The easiest way to do it is to use the script: `.githooks/linkallchecks.sh` and `.githooks/unlinkprepush.sh`. If you have a situation where you want to push without the checks, just `unlinkprepush.sh` and then put it back with `linkallchecks.sh`.
+The easiest way to do it is to use the script: `.githooks/linkallchecks.sh` and `.githooks/unlinkprepush.sh`. If you have a situation where you want to push without the checks, run `unlinkprepush.sh` and then put it back with `linkallchecks.sh`.
 
 But what you're actually doing is this:
 ```

.github/RELEASE_NOTES_TEMPLATE.md

@@ -7,7 +7,7 @@ See the [installation instructions](https://github.com/ddev/ddev/blob/master/doc
 `curl https://raw.githubusercontent.com/ddev/ddev/master/scripts/install_ddev.sh | bash`
 - Windows: Download the ddev_windows_installer above or `choco upgrade ddev`
 
-And anywhere, you can just download the tarball or zipball, un-tar or un-zip it, and place the executable in your path where it belongs.
+And anywhere, you can download the tarball or zipball, un-tar or un-zip it, and place the executable in your path where it belongs.
 
 # Caveats
 

CONTRIBUTING.md

@@ -16,7 +16,7 @@ If you find a bug in this project, have trouble following the documentation, or
 
 ## Stack Overflow Questions and Documentation
 
-There are a number of situations where a particular approach to a DDEV solution can be stated more easily in [Stack Overflow](https://stackoverflow.com/tags/ddev) (use the "ddev" tag). We respond there quickly, but if you know the answer already, create the question there and then click the checkbox at the bottom "Answer your own question". Stack Overflow is often the best place to incubate documentation that affects just a few people or that just needs time to get responses. And it's highly searchable on the web.
+There are a number of situations where a particular approach to a DDEV solution can be stated more easily in [Stack Overflow](https://stackoverflow.com/tags/ddev) (use the "ddev" tag). We respond there quickly, but if you know the answer already, create the question there and then click the checkbox at the bottom "Answer your own question". Stack Overflow is often the best place to incubate documentation that affects only a few people or that needs time to get responses. And it's highly searchable on the web.
 
 ## Pull Request
 

containers/ddev-ssh-agent/README.md

@@ -48,7 +48,7 @@ docker run -it --volumes-from=ssh-agent -e SSH_AUTH_SOCK=/.ssh-agent/socket ubun
 
 **Run script**
 
-You can run the `run.sh` script which will build the images for you, launch the ssh-agent and add your keys. If your keys are password protected (hopefully) you will just need to input your passphrase.
+You can run the `run.sh` script which will build the images for you, launch the ssh-agent and add your keys. If your keys are password protected (hopefully) you will need to input your passphrase.
 
 Launch everything:
 

docs/content/developers/maintainers.md

@@ -22,7 +22,7 @@ Not all maintainers can do all these things at any given time, but these are the
 ## Appropriate Use of Privileges
 
 * We prefer the forked-PR workflow for all code changes. There are a few cases where a branch-PR on `ddev/ddev`, but in general, to do a fix or a feature, do it on a branch on your fork, and submit it as a forked PR.
-* Even though you may have privileges to do things like push directly to the default branch of a repository, it doesn't mean you should use them. The vast majority of the time you'll use the codebase just like any other contributor. PRs make it clear both now and in the future why changes were made.
+* Even though you may have privileges to do things like push directly to the default branch of a repository, it doesn't mean you should use them. The vast majority of the time you'll use the codebase the same as any other contributor. PRs make it clear both now and in the future why changes were made.
 * Use clear PRs and write great issues even though you yourself may understand exactly what's going on. Remember that you may need a refresher course in what you did in a month or a year, so write a great PR description and fill in the form.
 * Remember to talk about configuration changes you make with other maintainers. Don't waste their time by changing things they'll then have to discover and debug.
 

docs/content/users/install/performance.md

@@ -82,7 +82,7 @@ Mutagen is enabled by default on Mac and traditional Windows, and it can be disa
     * **Perform big Git operations on the host side.**<br>
     Git actions that change lots of files, like switching branches, are best done on the host side and not inside the container. You may want to do an explicit `ddev mutagen sync` command after doing something like that to be sure all changes are picked up quickly.
     * **Share projects carefully with non-Mutagen users.**<br>
-    If you share a project with some users that want Mutagen, perhaps on macOS, and other users that don’t want or need it, perhaps on WSL2, don’t check in `.ddev/config.yaml`’s [`performance_mode: "mutagen"`](../configuration/config.md#performance_mode). Instead, either use [global performance mode configuration](../configuration/config.md#performance_mode) or add a not-checked-in, project-level `.ddev/config.performance.yaml` just to include `performance_mode: "mutagen"` in it. That way, only users with that file will have Mutagen enabled.
+    If you share a project with some users that want Mutagen, perhaps on macOS, and other users that don’t want or need it, perhaps on WSL2, don’t check in `.ddev/config.yaml`’s [`performance_mode: "mutagen"`](../configuration/config.md#performance_mode). Instead, either use [global performance mode configuration](../configuration/config.md#performance_mode) or add a not-checked-in, project-level `.ddev/config.performance.yaml` solely to include `performance_mode: "mutagen"` in it. That way, only users with that file will have Mutagen enabled.
     * **Windows symlinks have some Mutagen restrictions.**<br>
     On macOS and Linux (including WSL2) the default `.ddev/mutagen/mutagen.yml` chooses the `posix-raw` type of symlink handling. (See [mutagen docs](https://mutagen.io/documentation/synchronization/symbolic-links)). This basically means any symlink created will try to sync, regardless of whether it’s valid in the other environment. Mutagen, however, does not support `posix-raw` on traditional Windows, so DDEV uses the `portable` symlink mode. The result is that on Windows, using Mutagen, symlinks must be strictly limited to relative links that are inside the Mutagen section of the project.
     * **It’s a filesystem feature. Make backups!**<br>
@@ -239,7 +239,7 @@ Mutagen is enabled by default on Mac and traditional Windows, and it can be disa
         If your DDEV projects are set up outside your home directory, you’ll need to add a line to `/etc/exports` for that share as well:
 
         1. Run `sudo vi /etc/exports`.
-        2. Copy the line the script just created (`/System/Volumes/Data/Users/username -alldirs -mapall=<your_user_id>:20 localhost`).
+        2. Copy the line the script you created (`/System/Volumes/Data/Users/username -alldirs -mapall=<your_user_id>:20 localhost`).
         3. Edit to add the additional path, e.g:
         `/Volumes/SomeExternalDrive -alldirs -mapall=<your_uid>:20 localhost`.
 

docs/content/users/install/shell-completion.md

@@ -28,7 +28,7 @@ Shells like Bash and zsh need help to do this though, they have to know what the
 
     On Debian and Yum based systems, using `apt install ddev` you should find that `bash`, `zsh`, and `fish` completions are automatically installed.
 
-    Manual installation is easy though, the completion script is exactly the same, it’s just that you have to download and install it yourself. Each system may have a slightly different technique, and you’ll need to figure it out. On Debian/Ubuntu, manually install like this:
+    Manual installation is easy though, the completion script is exactly the same, but you have to download and install it yourself. Each system may have a slightly different technique, and you’ll need to figure it out. On Debian/Ubuntu, manually install like this:
 
     1. Download the completion files and extract them with
         ```bash

docs/content/users/quickstart.md

@@ -46,11 +46,11 @@ Environment variables will be automatically added to your `.env` file to simplif
     ddev launch
     ```
 
-    Third-party starter projects can by used the same way—just substitute the package name when running `ddev composer create`.
+    Third-party starter projects can by used the same way—substitute the package name when running `ddev composer create`.
 
 === "Existing projects"
 
-    You can start using DDEV with an existing project, too—just make sure you have a database backup handy!
+    You can start using DDEV with an existing project, too—but make sure you have a database backup handy!
 
     ```bash
     # Clone an existing repository (or navigate to a local project directory):

pkg/ddevapp/testdata/TestApptypeDetection/magento/README.md

@@ -52,7 +52,7 @@ To get the latest changes use:
 composer require openmage/magento-lts":"dev-main"
 ```
 
-<small>Note: `dev-main` is just an alias for current `1.9.4.x` branch and may change</small>
+<small>Note: `dev-main` is an alias for current `1.9.4.x` branch and may change</small>
 
 ### Using Git