git · chriscool · Oct 7, 2024 · Oct 2, 2024 · Oct 2, 2024 · Oct 2, 2024
diff --git a/General-Application-Information.md b/General-Application-Information.md
@@ -247,7 +247,7 @@ earlier than you. This means that you might have to find a project
 idea that we haven't proposed in our idea list.
 
 The good side of this is that this project idea along with your
-enthousiasm for it and the skills you show might encourage Git
+enthusiasm for it and the skills you show might encourage Git
 developers to mentor you even if they weren't planning to mentor in
 the first place. It could also happen that someone, who was only
 planning to co-mentor, could agree to fully mentor you alone.
diff --git a/General-Microproject-Information.md b/General-Microproject-Information.md
@@ -50,7 +50,7 @@ and the implementation of that design were all reviewed and discussed,
 and after several iterations an improved version of the patch was
 accepted into our codebase. As a GSoC contributor, or Outreachy intern,
 you will be playing the role of the developer and engaging in a
-similar discussion. Get familar with the flow, need for clarity on
+similar discussion. Get familiar with the flow, need for clarity on
 both sides (i.e. you need to clearly explain your design, and need to
 ask for clarifications when questions/suggestions you are offered are
 not clear enough), the pace at which the discussion takes place, and

diff --git a/Hacking-Git.md b/Hacking-Git.md
@@ -62,9 +62,9 @@ suggest improvements. Thanks!
 
 * [Sending patches by email with git](https://flusp.ime.usp.br/git/sending-patches-by-email-with-git/) is Matheus' git send-email tutorial.
 
-* [lore.kernel.org/git](https://lore.kernel.org/git/) is our prefered mailing list archive.
+* [lore.kernel.org/git](https://lore.kernel.org/git/) is our preferred mailing list archive.
 
-* [public-inbox](https://public-inbox.org/README.html) is the software behing lore.kernel.org.
+* [public-inbox](https://public-inbox.org/README.html) is the software behind lore.kernel.org.
 
 * [lore+lei](https://people.kernel.org/monsieuricon/lore-lei-part-1-getting-started) helps take advantage of lore/public-inbox.
 

diff --git a/Outreachy-21-Microprojects.md b/Outreachy-21-Microprojects.md
@@ -89,6 +89,6 @@ untracked file in the submodule directory. This is inconsistent with
 what `git describe --dirty` says when run in the submodule directory in
 that state.
 
-Fix `git diff` to use the same definition of dirtyness for such a
+Fix `git diff` to use the same definition of dirtiness for such a
 submodule directory (or the other way around).
 [[cf](https://lore.kernel.org/git/[email protected])]
diff --git a/SoC-2014-Microprojects.md b/SoC-2014-Microprojects.md
@@ -28,7 +28,7 @@ and the implementation of that design were all reviewed and discussed,
 and after several iterations an improved version of the patch was
 accepted into our codebase. As a GSoC student, you will be playing
 the role of the developer and engaging in a similar discussion. Get
-familar with the flow, need for clarity on both sides (i.e. you need
+familiar with the flow, need for clarity on both sides (i.e. you need
 to clearly defend your design, and need to ask clarifications when
 questions/suggestions you are offered are not clear enough), the pace
 at which the discussion takes place, and the general tone of the

diff --git a/SoC-2015-Ideas.md b/SoC-2015-Ideas.md
@@ -77,7 +77,7 @@ look for the commit which fixed a bug. It is already possible using
 "git bisect", but the user has to type "good" to mean "the bug is
 there" and "bad" to mean "the bug is fixed", which isn't convenient.
 
-It would be nice to allow the user to explicitely say "git bisect
+It would be nice to allow the user to explicitly say "git bisect
 fixed" and "git bisect unfixed" instead. It is actually much harder
 than defining "fixed"/"unfixed" as aliases for "bad"/"good".
 

diff --git a/SoC-2015-Microprojects.md b/SoC-2015-Microprojects.md
@@ -28,7 +28,7 @@ and the implementation of that design were all reviewed and discussed,
 and after several iterations an improved version of the patch was
 accepted into our codebase. As a GSoC student, you will be playing
 the role of the developer and engaging in a similar discussion. Get
-familar with the flow, need for clarity on both sides (i.e. you need
+familiar with the flow, need for clarity on both sides (i.e. you need
 to clearly defend your design, and need to ask clarifications when
 questions/suggestions you are offered are not clear enough), the pace
 at which the discussion takes place, and the general tone of the

diff --git a/SoC-2016-Ideas.md b/SoC-2016-Ideas.md
@@ -267,7 +267,7 @@ compressed data from one packfile to another.
 
 This would involve looking at the code in git to copy over
 optimisations as well as figuring out what parts of libgit2 should be
-changed to accomodate these new capabilities.
+changed to accommodate these new capabilities.
 
 - Language: C
 - Difficulty: medium

diff --git a/SoC-2016-Microprojects.md b/SoC-2016-Microprojects.md
@@ -40,7 +40,7 @@ and the implementation of that design were all reviewed and discussed,
 and after several iterations an improved version of the patch was
 accepted into our codebase. As a GSoC student, you will be playing
 the role of the developer and engaging in a similar discussion. Get
-familar with the flow, need for clarity on both sides (i.e. you need
+familiar with the flow, need for clarity on both sides (i.e. you need
 to clearly defend your design, and need to ask clarifications when
 questions/suggestions you are offered are not clear enough), the pace
 at which the discussion takes place, and the general tone of the
@@ -272,7 +272,7 @@ When you find something you are interested to work on, please ask
 first on the mailing list if it's worth doing and if it's appropriate
 for a microproject before starting to work on what you find. Even if
 it looks straitforward, there could be hidden reasons why it is too
-difficult or just innappropriate.
+difficult or just inappropriate.
 
 ### Searching the code base itself
 

diff --git a/SoC-2017-Microprojects.md b/SoC-2017-Microprojects.md
@@ -33,7 +33,7 @@ and the implementation of that design were all reviewed and discussed,
 and after several iterations an improved version of the patch was
 accepted into our codebase. As a GSoC student, you will be playing
 the role of the developer and engaging in a similar discussion. Get
-familar with the flow, need for clarity on both sides (i.e. you need
+familiar with the flow, need for clarity on both sides (i.e. you need
 to clearly defend your design, and need to ask clarifications when
 questions/suggestions you are offered are not clear enough), the pace
 at which the discussion takes place, and the general tone of the
@@ -262,7 +262,7 @@ When you find something you are interested to work on, please ask
 first on the mailing list if it's worth doing and if it's appropriate
 for a microproject before starting to work on what you find. Even if
 it looks straitforward, there could be hidden reasons why it is too
-difficult or just innappropriate.
+difficult or just inappropriate.
 
 ### Searching the code base itself
 

diff --git a/SoC-2018-Microprojects.md b/SoC-2018-Microprojects.md
@@ -33,7 +33,7 @@ and the implementation of that design were all reviewed and discussed,
 and after several iterations an improved version of the patch was
 accepted into our codebase. As a GSoC student, you will be playing
 the role of the developer and engaging in a similar discussion. Get
-familar with the flow, need for clarity on both sides (i.e. you need
+familiar with the flow, need for clarity on both sides (i.e. you need
 to clearly defend your design, and need to ask clarifications when
 questions/suggestions you are offered are not clear enough), the pace
 at which the discussion takes place, and the general tone of the

diff --git a/SoC-2019-Ideas.md b/SoC-2019-Ideas.md
@@ -120,7 +120,7 @@ projects versus projects that implement new features though.
 Git has an old problem of duplicated implementations of some
 logic. For example, Git had at least 4 different implementations to
 format command output for different commands. Our previous GSoC
-students and Outreachy interns unified some of the formating logic
+students and Outreachy interns unified some of the formatting logic
 into [ref-filter](https://github.com/git/git/blob/master/ref-filter.h)
 and got rid of similar logic in some command specific files. Current
 task is to continue this work and reuse ref-filter formatting logic in

diff --git a/SoC-2019-Microprojects.md b/SoC-2019-Microprojects.md
@@ -33,7 +33,7 @@ and the implementation of that design were all reviewed and discussed,
 and after several iterations an improved version of the patch was
 accepted into our codebase. As a GSoC student, you will be playing
 the role of the developer and engaging in a similar discussion. Get
-familar with the flow, need for clarity on both sides (i.e. you need
+familiar with the flow, need for clarity on both sides (i.e. you need
 to clearly defend your design, and need to ask clarifications when
 questions/suggestions you are offered are not clear enough), the pace
 at which the discussion takes place, and the general tone of the

diff --git a/SoC-2020-Ideas.md b/SoC-2020-Ideas.md
@@ -27,7 +27,7 @@ page though.
 Git has an old problem of duplicated implementations of some
 logic. For example, Git had at least 4 different implementations to
 format command output for different commands. Our previous GSoC
-students and Outreachy interns unified some of the formating logic
+students and Outreachy interns unified some of the formatting logic
 into [ref-filter](https://github.com/git/git/blob/master/ref-filter.h)
 and got rid of similar logic in some command specific files. Current
 task is to continue this work and reuse ref-filter formatting logic in

diff --git a/SoC-2021-Ideas.md b/SoC-2021-Ideas.md
@@ -32,7 +32,7 @@ possible the same code and syntax as the ref-filter formats.
 Git used to have an old problem of duplicated implementations of some
 logic. For example, Git had at least 4 different implementations to
 format command output for different commands. Our previous GSoC
-students and Outreachy interns unified some of the formating logic
+students and Outreachy interns unified some of the formatting logic
 into [ref-filter](https://github.com/git/git/blob/master/ref-filter.h)
 and got rid of similar logic in some command specific files.
 

diff --git a/SoC-2022-Ideas.md b/SoC-2022-Ideas.md
@@ -83,7 +83,7 @@ logic. For example, Git had at least 4 different implementations to
 format command output for different commands.
 
 Our previous GSoC students and Outreachy interns unified some of the
-formating logic into
+formatting logic into
 [ref-filter](https://github.com/git/git/blob/master/ref-filter.h) and
 got rid of similar logic in some command specific files. Current task
 is to continue this work and reuse ref-filter formatting logic in

diff --git a/SoC-2023-Ideas.md b/SoC-2023-Ideas.md
@@ -77,7 +77,7 @@ logic. For example, Git had at least 4 different implementations to
 format command output for different commands.
 
 Our previous GSoC students and Outreachy interns unified some of the
-formating logic into
+formatting logic into
 [ref-filter](https://github.com/git/git/blob/master/ref-filter.h) and
 got rid of similar logic in some command specific files. Current task
 is to continue this work and reuse ref-filter formatting logic in

diff --git a/_posts/2015-04-15-edition-2.markdown b/_posts/2015-04-15-edition-2.markdown
@@ -169,7 +169,7 @@ His patch does basically:
 ```
 
 Duy Nguyen suggested instead to avoid any FILE* interface and either
-mmap the entire file, or read (with bufferring) from a file
+mmap the entire file, or read (with buffering) from a file
 descriptor, as Git already does to read the index-pack file. But Peff
 said that it would be very inefficient too, and that there are no good
 NUL safe function to read from a file descriptor.

diff --git a/_posts/2015-05-13-edition-3.markdown b/_posts/2015-05-13-edition-3.markdown
@@ -56,12 +56,12 @@ colors.
 When people have finished documenting everything, which is anyway a
 good thing, then Git commands can be introduced in the context in
 which they are useful. For example as people are drawing boxes and
-arrows on diagrams, they can be teached the `git clone`, `git push`
+arrows on diagrams, they can be taught the `git clone`, `git push`
 and other Git commands that can be associated with the code sharing
 arrows.
 
 Teaching this way makes people 'build' their knowledge, talk to each
-other about their workflows and visualy document their use of
+other about their workflows and visually document their use of
 Git.
 
 This whole process makes Git more accessible and friendly, which is
@@ -141,8 +141,8 @@ Sébastien's work is very welcome.
 
 Unfortunately git developers can have different views on how to group
 commands together. So it can be difficult for them to agree on such
-kind of changes. Long discussions because of small personnal
-preferences - we call that bikesheedding - can sometimes go on for a
+kind of changes. Long discussions because of small personal
+preferences - we call that bikeshedding - can sometimes go on for a
 while.
 
 In the case of Sébastien's patch series, many developers helped or got

diff --git a/_posts/2015-08-05-edition-6.markdown b/_posts/2015-08-05-edition-6.markdown
@@ -122,7 +122,7 @@ Then Linus Torvalds explained the situation this way:
 > an "evil merge" is something that makes changes that came from neither
 > side and aren't actually resolving a conflict.
 
-Linus then started a discussion about wether the `-p` option in `git
+Linus then started a discussion about whether the `-p` option in `git
 log` should imply `--cc`:
 
 > That said, I do wonder if we should just make "-p" imply "--cc". Right

diff --git a/_posts/2015-09-09-edition-7.markdown b/_posts/2015-09-09-edition-7.markdown
@@ -212,7 +212,7 @@ entries has only two bytes. The limit is then 65535 entries.
 René then sent a patch series to add tests for this problem and then
 fix it. The first patch contains the following code, which tests that
 a suitable `zipinfo` command is available on the current machine, and
-sets the ZIPINFO prerequesite if this is the case:
+sets the ZIPINFO prerequisite if this is the case:
 
 ```
 +ZIPINFO=zipinfo

diff --git a/_posts/2015-10-14-edition-8.markdown b/_posts/2015-10-14-edition-8.markdown
@@ -84,7 +84,7 @@ to git/git, and Lars has since posted
 [a version 2](https://public-inbox.org/git/1443981977-64604-1-git-send-email-larsxschneider%40gmail.com/)
 and [a version 3 of his
 patches](https://public-inbox.org/git/1444586102-82557-1-git-send-email-larsxschneider%40gmail.com/),
-so an interesting way to test patchs will perhaps be available soon
+so an interesting way to test patches will perhaps be available soon
 to Git developers.
 
 
@@ -271,7 +271,7 @@ __Git tools and sites__
 
 * [git-nerps](https://github.com/mk-fg/git-nerps) - Tool to encrypt and manage selected files (or parts of files) in a Git repository. See also the [blog post](http://blog.fraggod.net/2015/09/01/transparent-and-easy-encryption-for-files-in-git-repositories.html) by its creator, Mike Kazantsev.
 * [git-ftp](http://git-ftp.github.io/git-ftp/) - Git powered FTP client written as shell script
-* [git-punish](http://git-punish.io/) - more for fun than anything else, this is a shortcut for runnig git blame and posting it's output to [git-punish.io](http://git-punish.io)
+* [git-punish](http://git-punish.io/) - more for fun than anything else, this is a shortcut for running git blame and posting it's output to [git-punish.io](http://git-punish.io)
 * [git:ghost](http://gitghost.org/) - Publish posts to your Ghost blog using git
 * [Helix GitSwarm](http://www.perforce.com/downloads/helix-gitswarm) - a joint effort between Perforce and GitLab
 * [Tower's resources for learning Git](http://www.git-tower.com/learn/) - not sure if this is new, but it hasn't been in our newsletter yet.

diff --git a/_posts/2016-01-13-edition-11.markdown b/_posts/2016-01-13-edition-11.markdown
@@ -38,7 +38,7 @@ and:
 
 It's interesting because there has been a lot of work during the past
 years to develop news ways to store refs. Especially there has been
-[attemps to store refs in databases like LMDB](https://public-inbox.org/git/1441245313-11907-1-git-send-email-dturner%40twopensource.com/), that have been covered in
+[attempts to store refs in databases like LMDB](https://public-inbox.org/git/1441245313-11907-1-git-send-email-dturner%40twopensource.com/), that have been covered in
 [Git Rev News edition 7](https://git.github.io/rev_news/2015/09/09/edition-7/).
 
 This new approach tries to store refs using git's own object database
@@ -52,7 +52,7 @@ Following some comments by Junio, Shawn agreed that his implementation
 has some hacks to handle "HEAD", which is a special ref, and to handle
 the fact that gitlinks were made to only point to commits, not tags.
 
-Michael Haggerty wondered if the negociation phase that happens when
+Michael Haggerty wondered if the negotiation phase that happens when
 doing a 'git fetch' could be sped up by such an implementation. This
 started a discussion between Shawn, Junio and Michael about how the
 "refs/" hierarchy could be improved.
@@ -85,7 +85,7 @@ specific to each worktree and some that are not.
 There are two pattern lists. One is a default pattern list built into
 the git binary, and the other one in ".git/info/config.worktree" is a
 user writable pattern list. Those two pattern lists are merged
-internaly to specify which config options are worktree specific.
+internally to specify which config options are worktree specific.
 
 The worktree specific config options should then be put in
 ".git/worktrees/NAME/config.worktree" where NAME is a specific
@@ -101,7 +101,7 @@ Max Kirillov first suggested the following:
 > mark repositories which use per-worktree config with an
 > extension?
 
-Max is refered to the extension mechanism that has been released in
+Max is referred to the extension mechanism that has been released in
 the brand new Git 2.7.0 and that
 [was mentioned in some places](http://lwn.net/Articles/668163/).
 

diff --git a/_posts/2016-02-10-edition-12.markdown b/_posts/2016-02-10-edition-12.markdown
@@ -97,7 +97,7 @@ Peff also investigated different ways to fix it but concluded:
 > ever of removing it.
 
 and then sent a patch to "drop support for git-over-rsync". This
-patch, on top of explaning the above, contains:
+patch, on top of explaining the above, contains:
 
 > We never made an official deprecation notice in the release
 > notes for git's rsync protocol, but the tutorial has marked

diff --git a/_posts/2016-04-20-edition-14.markdown b/_posts/2016-04-20-edition-14.markdown
@@ -97,7 +97,7 @@ must be run manually for now, and running daemons on Windows
 might require some admin rights.
 
 The recently merged effort on improving the untracked cache in the
-index was also mentionned.
+index was also mentioned.
 
 * [Linux Kernel Development - Going Faster Than You Think](https://github.com/gregkh/kernel-development)
 
@@ -129,7 +129,7 @@ This makes the Linux Kernel the largest software project ever.
 Around 10 000 lines are added, 5300 lines are removed, and 1800 lines
 are modified, everyday!
 
-That's on average 7.8 changes per hour accross the whole tree with 5%
+That's on average 7.8 changes per hour across the whole tree with 5%
 in the core, 10% in the networking subsystem, and 55% in the drivers.
 
 This goes against any previously thought methodology for stable

diff --git a/_posts/2016-05-11-edition-15.markdown b/_posts/2016-05-11-edition-15.markdown
@@ -52,7 +52,7 @@ Another activity is related to defending the license, which is the
 GPLv2. For example, there have previously been vendors distributing
 Git with some changes, but without providing the source code for the Git version they
 were distributing. So far it has been possible to resolve these cases, but
-it is not completely clear if all vendors are currently fullfilling all of
+it is not completely clear if all vendors are currently fulfilling all of
 their obligations. If any developers who have contributed to Git
 want to take a closer look at what the vendors are doing, Conservancy is
 able to help them.
@@ -165,7 +165,7 @@ just after having run `git grep`.
 
 This year only one student, Pranit Bauva, will participate in the
 Google Summer of Code 2016 under the Git project. He will work on
-incrementaly rewriting in C the parts of "git bisect" that are still
+incrementally rewriting in C the parts of "git bisect" that are still
 in shell. He will be mentored by Lars Schneider and Christian Couder.
 
 ## Developer Spotlight: David Turner
@@ -253,7 +253,7 @@ __Various__
 * [Fun with a new feature in recent Git](https://git-blame.blogspot.de/2016/05/fun-with-new-feature-in-recent-git.html) by Junio C Hamano
 * [4200 miles, 5GBs, 1 min: cloning with mirrors and Git LFS](http://blogs.atlassian.com/2016/04/bitbucket-data-center-smart-mirroring-with-git-lfs-support/) from Atlassian's Kelvin Yap
 * [GitHub: Import repositories with large files](https://github.com/blog/2163-import-repositories-with-large-files), by Jonathan Hoyt
-* [Git Tips, Tricks and Workflows](http://www.fullstackradio.com/41) from the Full Stack Radio podcast epsiode 41, featuring Jason McCreary
+* [Git Tips, Tricks and Workflows](http://www.fullstackradio.com/41) from the Full Stack Radio podcast episode 41, featuring Jason McCreary
 * [One Commit. One Change.](https://medium.com/@fagnerbrack/one-commit-one-change-3d10b10cebbf#.1zqmjhd8q) by Fagner Brack
 * [Fast-Forward and parent reversal](http://dwim.me/2016/01/11/fast-foward-and-parent-reversal.html) by Carlos Martín Nieto
 * An interesting way of collecting your Git tricks using the [Gingko App](https://gingkoapp.com/git-notes)