"Fix" the Markdown formatting

This uses the MarkdownLint extension for VSCode to rationalize the formatting on all the Markdown files.

PART_1_SHARE_INFO.md

@@ -42,12 +42,12 @@ will create a copy on GitHub for your team of our starter
 repository; your team will use that as the starting point for your work.
 
 This lab is unusual in that we will all be on a single large team called
-__Everyone__, all making changes to a single shared repository. This will
+**Everyone**, all making changes to a single shared repository. This will
 help illustrate the value of version control systems like `git` in managing
 this kind of shared resource, and also give us opportunities to see what
 happens when different people make inconsistent changes to the same files.
 
-So follow the link in the Canvas assignment and join the __Everyone__ team;
+So follow the link in the Canvas assignment and join the **Everyone** team;
 that should take you to the shared repository on GitHub. From there
 you can get the URL for that repository
 from the green `Code` button visible on the "home page" for each

PART_2_JAVA_INTRODUCTIONS.md

@@ -347,7 +347,7 @@ The meaning of these symbols is:
   the tests passed, and any other checks passed as well).
 - ![GitHub's red failure x][red-x]: A red x means that
   something bad happened, like a test failed.
-  
+
 If you click on any of these symbols on the GitHub page, you can get
 more information, including links to pages with details on, e.g., failed tests.
 
@@ -493,7 +493,7 @@ Here, if Chris clicks the "Resolve conflicts" button, GitHub will put Chris in
 a (web) editor where they can resolve the conflicts. That editor will likely
 have a section that looks something like:
 
-```java
+```diff
 <<<<<<< chris-greeting
     builder.append(chrisSaysHello());
 =======
@@ -590,12 +590,12 @@ look over the code and make sure the changes look reasonable. Some things to
 check for:
 
 - [ ] Does it look (by eye) that this will print all the greetings in alphabetical
-  order? (The tests check that for sure, but you should always be thinking about
-  correctness as well.)
+      order? (The tests check that for sure, but you should always be thinking about
+      correctness as well.)
 - [ ] Do the new methods they're adding have reasonable names that convey useful
-  info to the reader?
+      info to the reader?
 - [ ] Are new method names in camel cases, starting in lowercase (the Java standard
-  for method names)?.
+      for method names)?.
 - [ ] Is the implementation of the new methods reasonable?
 - [ ] Is the spacing and indentation uniform and consistent with the rest of the file?
 

README.md

@@ -9,12 +9,12 @@
 >
 > - [ ] Create a team called "Everyone"
 > - [ ] Fix the URLs in the badges below so they point to that semester's
->     repository instead of the "starter" repo.
+>       repository instead of the "starter" repo.
 > - [ ] Make sure we've added every student in the current semester
->     to that semester's organization so they'll have permission to
->     push to this repo.
+>       to that semester's organization so they'll have permission to
+>       push to this repo.
 > - [ ] [Turn off branch protection](docs/FACULTY_BRANCH_PROTECTION_SETTINGS.md)
->     so that students can `push`.
+>       so that students can `push`.
 > - [ ] Remove this note and the broken badge above in the fork.
 >
 > We should leave these notes in the copy in the "starter"
@@ -88,9 +88,9 @@ its more advanced features.
 
 - The excellent [Atlassian `git` tutorials](https://www.atlassian.com/git/tutorials/what-is-version-control)
 - [The "standard" `git` documentation site](https://git-scm.com/documentation),
-which also includes links to videos, cheat sheets, and such
+  which also includes links to videos, cheat sheets, and such
 - [`git` – the simple guide](http://rogerdudler.github.io/git-guide/),
-a single-page app that goes through the major features of `git`
+  a single-page app that goes through the major features of `git`
 - [A little on-line "game" for learning how branching works in `git`](https://learngitbranching.js.org/)
 
 As circumstances allow, you might also want to at least skim one or two of the

docs/MERGE_CONFLICTS.md

@@ -1,6 +1,6 @@
 # Info on merge conflicts <!-- omit in toc -->
 
-- [What is a merge conflict & why do they matter?](#what-is-a-merge-conflict--why-do-they-matter)
+- [What is a merge conflict \& why do they matter?](#what-is-a-merge-conflict--why-do-they-matter)
 - [Pro-tip: Keep your branch(es) up-to-date](#pro-tip-keep-your-branches-up-to-date)
 - [How to deal with merge conflicts](#how-to-deal-with-merge-conflicts)
   - [Make sure you have the latest version of `main` locally](#make-sure-you-have-the-latest-version-of-main-locally)
@@ -144,7 +144,7 @@ your feature branch.
   Go with the first one (probably "Merge", but possibly "Fast-forward").
 - On the command line
   - Run `git checkout my-cool-feature` to check out the
-  feature branch
+    feature branch
   - Then run `git merge main` to merge in the new changes from `main`.
     - On the command line, `git merge <branch-name>` will merge the specified
       branch into whichever branch is currently checked out.

user_info/KK_and_Nic.md

@@ -8,14 +8,14 @@ until something interesting came up.
 
 ## Kristin Lamberty
 
-* I preferred to be called "KK".
-* My preferred pronouns are she/her/hers.
-* My GitHub username is `kklamberty`.
-* My GitHub "home page" is [github.com/kklamberty](https://github.com/kklamberty/).
+- I preferred to be called "KK".
+- My preferred pronouns are she/her/hers.
+- My GitHub username is `kklamberty`.
+- My GitHub "home page" is [github.com/kklamberty](https://github.com/kklamberty/).
 
 ## Nic McPhee
 
-* I preferred to be called "Nic".
-* My preferred pronouns are he/him/his.
-* My GitHub username is `NicMcPhee`.
-* My GitHub "home page" is [github.com/NicMcPhee](https://github.com/NicMcPhee/).
+- I preferred to be called "Nic".
+- My preferred pronouns are he/him/his.
+- My GitHub username is `NicMcPhee`.
+- My GitHub "home page" is [github.com/NicMcPhee](https://github.com/NicMcPhee/).