Minor typos

Author: jericson

_posts/2021-08-24-git_rewrite_1.md

@@ -193,7 +193,7 @@ type of file.
 This is _unlimited linear growth_. Each time we built out we increased
 the size of the repo by roughly the size of our PDFs after [zlib
 compression](https://en.wikipedia.org/wiki/Zlib). By design, Git
-repositories never get smaller. It's a ratcheting effect that needless
+repositories never get smaller. It's a ratcheting effect that needlessly
 chewed up disk space and bandwidth for everyone who contributes to the
 project. It had to stop.
 
@@ -270,5 +270,5 @@ our story just now.
 [^5]: Git also compresses blobs and uses
     [packfiles](https://git-scm.com/book/en/v2/Git-Internals-Packfiles)
     to reduce the size of the repository. Interestingly, packfiles
-    work on a similarly to changesets except they can group similar
+    work similarly to changesets except they can group similar
     content even if it's not strictly speaking the same file.

_posts/2021-09-06-git_rewrite_2.md

@@ -140,12 +140,11 @@ But this is really terrible grammar that only a computer could love. Let's rewor
 > When there is a  `push` `on`  the `develop` `branch` . . . 
 
 I haven't talked about branches just yet, but this is feature of Git
-that allows people to work on different projects using the same code
-without stepping on each other's toes. It creates an alternate
-timeline that won't interfere with other timelines until someone
-decides to merge them. The important thing is that this particular
-workflow happens every time someone submits a change to the `develop`
-branch.
+that allows several people to work on the same code without stepping
+on each other's toes. It creates an alternate timeline that won't
+interfere with other timelines until someone decides to merge
+them. The important thing is that this particular workflow happens
+every time someone submits a change to the `develop` branch.
 
 What happens? Well that's defined in the second half of the file:
 
@@ -225,7 +224,7 @@ defining steps, but they boil down to:
 
 The crux of the problem, [as I previously
 explained]((/2021/08/24/git_rewrite_1.html)), is that we checked in
-PDFs files which caused our repository to grow without limit. So all
+PDF files which caused our repository to grow without limit. So all
 we need to do is eliminate step #3 there.
 
 Trouble is we want to keep PDFs indefinitely. So we need to store them
@@ -289,6 +288,7 @@ we've created have been overtaken by events.
 That said, the nifty thing about Git keeping all that history _and_
 using commodity compute power is that we can more or less re-generate
 any PDF we've ever created in the past. All we need to do is:
+
 1. Log into a computer with the same configuration as the computer we
 used to generate PDFs. (In our case, that's one running
 `ubuntu-20.04`.)  

_posts/2023-09-01-git_rewrite_3.md

@@ -157,9 +157,6 @@ sent out emails to everyone I had a reason to suspect had make a
 copy. And then I moved on content in the knowledge that only some disk
 space, and not the space-time continuum itself, was at risk.
 
----
-
-
 [^1]: I [no longer work at EDB](/2022/06/13/year_at_edb.html), but I
     found this draft and decided to finish writing it. Hopefully I
     remember enough to be informative!